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Human-Centered  Command  and  Control  of  Future  Autonomous  Systems 


Abstract 

The  DoD's  envisioned  role  shift  for  humans  from  operators  to  future  autonomous  systems  supervisors 
presents  significant  challenges  for  developing  effective  decision  support.  What  decision  support  will 
supervisors  need  to  effectively  oversee  autonomous  systems?  What  will  their  task  needs  be  and  how 
can  we  support  them  with  usable  and  useful  supervisory  human-machine  interfaces  (HMIs)  and  tools? 
Here,  we  inform  the  requirements  and  design  of  future  decision  support  through  a  systematic  cognitive 
engineering  and  analysis  process.  Structured  interviews  with  27  unmanned  systems  experts  were 
carefully  sequenced  across  four  groups,  with  results  and  artifacts  from  one  group  informing  the  next 
interviews.  Interviews  focused  on  supervisory  monitoring  and  intervention  tasks  and  were  designed  to 
feed  a  user-  and  task-centered,  scientifically-principled  HMI  design  process  to  develop  the  decision 
support.  The  interviews  informed  this  design  process  by  populating  three  key  design  artifacts:  (1)  a 
model  of  current  and  future  tasks,  (2)  their  allocation  across  humans  and  automation,  and  (3)  the 
necessary  supporting  human-automation  exchanges.  A  framework  for  system  designers  to  allocate  tasks 
across  humans  and  automation  was  extended  to  provide  an  objective  basis  for  subject  matter  experts  to 
contribute  their  expectations  for  future  automation.  The  interview  results  show  how  today's  task  needs 
are  not  met  by  current  HMIs  and  tools,  and  how  persisting  with  them  is  unlikely  to  meet  the  future 
needs  of  more  nuanced  supervisory  decision  making.  Our  results  inform  the  design  of  future  supervisory 
HMIs  that  target  and  mitigate  today's  capability  gaps  and  shed  light  on  how  to  begin  to  achieve  the  DoD 
vision. 

Keywords:  supervisory  control,  autonomous  systems,  decision  support,  human-machine  interface,  user- 
centered  design 

Introduction 

The  Evolving  Role  of  the  Human  in  Unmanned  and  Autonomous  Systems 

The  role  of  the  human  operator  of  autonomous  systems  is  anticipated  to  undergo  a  significant 
transformation  from  today's  single-vehicle,  single-mission  operator  into  tomorrow's  multi-vehicle,  multi¬ 
mission  manager  (DoD,  2009).  Dramatic  improvements  and  increases  in  autonomy  are  expected  to 
enable  this  transformation  (DoD,  2012).  The  DoD  is  investing  heavily  in  researching  and  developing  the 
autonomy  technologies  required  to  support  the  future  vision.  Here,  we  focus  on  the  equally  important 
but  often  neglected  issue  of  supporting  the  future  human  end-user  of  these  technologies  who  must 
supervise  the  autonomous  systems  and  manage  multiple  concurrent  missions. 

Supporting  the  future  human  supervisor  means  anticipating  and  supporting  their  task  needs  as  they 
change  from  monitoring  vehicles  and  sensors  today  to  monitoring  mission-level  goals,  tasks,  and  status 
in  the  future  (see  Figure  1).  Future  users  will  supervise  vehicle-  and  sensor-related  automation  for 
multiple  vehicles  and  missions.  Given  that  different  tasks  require  different  tools  and  displays  (Larkin  & 
Simon,  1987;  St.  John,  Oonk,  Smallman  &  Cowen,  2001),  the  shift  to  supervisory  tasks  will  require 
careful  selection  and  (re)design  of  tools  and  displays  to  support  them.  We  have  recently  analyzed  the 
tendency  across  work  domains  to  inappropriately  keep  legacy  displays  and  display  "metaphors"  even 
when  they  inadequately  support  users'  tasks.  We  relate  this  tendency,  in  part,  to  flawed  intuitions  about 
the  effectiveness  of  certain  display  formats  (Smallman  &  Cook,  2013;  Smallman  &  St.  John,  2005).  These 
issues  only  heighten  the  need  to  carefully  address  the  new  task  requirements  for  autonomous  systems. 
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and  to  ensure  that  the  display  metaphors  and  tools  developed  align  with  these  new  task  needs. 

How  can  we  understand  and  support  these  new  task  needs?  Here,  we  report  work  on  a  task-  and  user- 
centered  design  (UCD)  approach  to  supervisory  decision  support  and  human-machine  interface  (HMI) 
design  for  future  autonomous  system  supervision.  Such  an  approach  is  critical  to  ensuring  that  the 
system  and  automation  are  engineered  around  the  needs  of  the  user  (Diaper  &  Stanton,  2004;  Norman, 
1986).  We  focus  specifically  on  monitoring  and  problem  intervention  tasks  during  mission  execution. 


Figure  1.  DoD's  envisioned  role  transformation  from  today's  multi-operator,  single-vehicle  control  to  a 
future  supervisor  of  highly  automated  and  autonomous  systems. 


Tailored  User-Centered  Design  (UCD)  Approach 

UCD  is  an  approach  to  human-computer  interaction  design  that  makes  supporting  the  user  and  their 
needs  the  paramount  goal  of  design  (Norman,  1986).  UCD  approaches  stem  from  Norman  and  Draper's 
book  User-Centered  System  Design  (1986),  with  design  principles  (Norman,  1988),  "rules"  (Shneiderman, 
1987),  and  heuristics  for  usability  engineering  (Nielsen,  1993,  2000)  all  emerging  and  evolving  over  time. 
For  example,  the  Ecological  Interface  Design  approach  borne  from  ecological  psychology  stresses 
engineering  sophisticated  domain  understanding  into  tool  design  (Bennett  &  Flach,  2011;  Vicente  & 
Rasmussen,  1992).  Other  approaches  stem  from  notions  of  situated  cognition  and  focus  on  respecting 
the  joint  nature  of  engineered  cognitive  systems  (Woods  &  Roth,  1988).  Still  others  focus  on  applying  a 
UCD  philosophy  within  modern  agile  software  development  (e.g.,  Osga,  2006).  In  general,  the  UCD 
process  begins  with  user  requirements  analysis  and  progresses  through  a  series  of  iterative  design 
prototyping  and  review  spirals.  Here,  we  were  faced  with  several  complex  and  unique  domain 
challenges  that  shaped  and  tailored  our  specific  UCD  approach. 

First,  we  are  designing  for  a  situation  and  a  user  population  that  does  not  yet  exist.  User  task  needs  are 
not  yet  defined,  and  cannot  be  specified  using  traditional  methods  of  analyzing  existing  work  on  existing 
systems  performed  by  existing  users.  Additionally,  future  automation  capabilities  are  still  being  defined 
and  can  only  be  estimated. 

Second,  the  current  team  and  role  structure  will  need  to  be  re-aligned  to  fit  a  single  supervisor  in  the 
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future1.  The  work  performed  by  two  or  three  humans  today  will  be  performed  in  the  future  by  a  single 
user  and  a  suite  of  automation  jointly  managing  multiple  vehicles  and  missions  (DoD,  2009).  The  use  of 
automation  is  often  referred  to  as  a  "double-edged  sword"  to  denote  its  potential  to  reduce  user 
workload  and  improve  efficiency,  but  also  to  introduce  challenges  with  situation  awareness,  automation 
reliance,  and  accountability  (Bainbridge,  1983).  If  not  carefully  designed  and  integrated  into  users'  tasks, 
automation's  costs  can  quickly  outweigh  its  benefits.  A  tempting  solution  to  compensate  for  inherent 
human  cognitive  limitations  is  to  introduce  even  more  automation  (e.g.,  automated  monitoring  of 
automation);  however,  this  approach  introduces  yet  another  system  that  a  user  needs  to  monitor 
(Parasuraman  &  Riley,  1997),  further  complicating  the  situation.  Despite  the  general  guidance  and  lists 
of  issues  to  consider  for  designing  automation  and  associated  HMIs,  there  is  currently  no  "universal 
formula  for  automating  systems"  (OSD,  2012). 

Third,  design  must  occur  within  the  constraints  of  system  development.  Large-scale  military  and  industry 
system  development  tends  to  be  centered  more  on  technology  and  less  on  user  needs,  and  generally 
aims  to  minimize  change.  Although  the  reasons  for  these  tendencies  may  be  just,  the  effects  on  user  and 
system  performance  tend  to  be  negative.  A  technology-centric  focus  has  resulted  in  inadequate  or  even 
failed  systems  (e.g.,  Tvaryanas,  2012).  The  tendency  to  maintain  legacy  systems  and  minimize  change 
has  been  a  barrier  to  improvement;  several  of  the  human  factors-related  issues  identified  in  analyses 
from  almost  a  decade  ago  (e.g.,  Tvaryanas,  2004;  Williams,  2004)  linger  in  many  of  today's  unmanned 
systems  and  HMIs.  These  issues  impact  several  aspects  of  unmanned  system  operation  and  safety. 
Human  causal  factors  have  been  implicated  in  the  majority  of  unmanned  aircraft  system  (UAS)  mishaps 
from  1994-2003  (Tvaryanas,  Thompson,  &  Constable,  2006).  Although  UAS  accident  rates  have  generally 
declined  over  the  years,  accident  rates  within  the  US  Air  Force  are  currently  higher  for  the  three  largest 
UAS  than  for  other  aircraft  categories2  (Bloomberg,  2012).  The  fact  that  today's  control  systems  and 
HMIs  for  unmanned  vehicles  are  already  straining  to  support  effective  single  vehicle  operation  raises 
concerns  for  their  ability  to  support  multiple  vehicle  missions  in  the  future.  Causing  further  concern  is 
the  limited  success  of  previous  attempts  to  increase  the  number  of  vehicles  per  operator  (e.g..  Predator 
Multi-Aircraft  Capability  (MAC)). 

We  developed  and  employed  a  UCD  process  tailored  to  address  these  challenges  and  constraints  in  the 
development  of  future  decision  support,  see  Figure  2.  This  modified  UCD  process  is  unique  in  its 
flexibility,  domain-grounding,  and  scientifically-principled  approach.  It  leverages  the  unique  expertise 
and  recognizes  the  limitations  of  each  stakeholder  (e.g.,  subject  matter  experts  (SMEs),  human  factors 
scientists/designers),  and  assigns  stakeholders  roles  accordingly.  For  example,  SME  feedback  was 
focused  on  expectations  for  future  automation  based  on  extensive  experience  with  unmanned  vehicles, 
rather  than  subjective  preferences  for  display  designs,  given  the  limits  in  SME  intuition  about  displays 
revealed  by  our  recent  Naive  Realism  research  in  metacognition  and  visual  displays  (Smallman  &  Cook, 
2011).  The  role  of  the  human  factors  scientists  and  designers  was  to  apply  expertise  in  cognitive  science, 
human-automation  allocation,  and  relevant  work  domains  to  develop  concepts  to  meet  future 
supervisory  work  domain  and  task  needs.  Figure  2  shows  the  general  steps  of  UCD  (middle),  and  how  we 
tailored  it  to  apply  cognitive  science  (top)  and  domain  expertise  (bottom)  at  key  points  throughout  the 
process  to  support  user  abilities  and  future  user  task  needs. 


1  The  future  vision  will  undoubtedly  involve  multiple  human  supervisors  interacting  and  collaborating.  Our  specific 
focus  in  the  current  work  is  on  the  general  transformation  of  the  human  role  from  operator  to  supervisor. 

2  The  combined  accident  rate  of  the  Air  Force's  three  largest  UAS  (9.31  per  100,000  hours  of  flight  for  Global  Hawk, 
Predator,  and  Reaper)  is  currently  the  highest  rate  for  any  aircraft  category,  and  more  than  three  times  as  high  as 
the  fleet-wide  average  of  3.03  per  100,000  hours  of  flight  (Bloomberg,  2012). 
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In  this  paper,  we  focus  on  the  first  three  UCD  steps  (shown  in  color  in  Figure  2)  and  how  they  provide  a 
principled  basis  for  the  design  of  systems,  automation,  and  HMIs  for  the  future  autonomous  systems 
supervisor.  These  three  steps  were  to  (1)  define  the  key  tasks  in  unmanned  system  operation  and 
supervision,  (2)  specify  the  allocation  of  those  tasks  to  humans  and  automation  currently  and  for  the 
future,  and  (3)  specify  the  necessary  information  exchanges  between  humans  and  automation  for 
effective  supervision. 


( 


Apply  cognitive  science  to  support  user  abilities  - 


Cognitive  Human- 

Cognitive  task  automation  "Monitoring"'  Cognitive 

challenges  analyses  allocation  work  domains  science 


A 


Performance 

tradeoffs 


Operational  Task,  Automation 

docs  domain  allocation 

feedback  feedback 


Info 

exchanges 


User  task  & 
display  constraints 


Feedback  on 
concepts,  usage 


'Apply  domain  expertise  to  support  future  task,  needs 

Total  of  27  military  and  industry  unmanned  systems  subject  matter  experts  (SMEs} 


Figure  2.  Highlights  of  user-centered  design  (UCD)  process  tailored  for  this  effort. 

This  approach  addressed  each  of  the  challenges  mentioned  above.  First,  by  carefully  specifying  the  core 
tasks  involved  in  unmanned  systems  operation  and  supervision,  we  provide  o  basis  for  defining  future 
user  task  needs.  Given  the  same  core  work  performed  currently  will  still  need  to  be  completed  in  the 
future,  what  will  change  is  how  the  work  gets  accomplished.  Therefore,  we  harnessed  expertise  from 
current  SMEs  with  experience  in  vehicle,  sensor,  and  mission  commander  unmanned  vehicle  roles  to 
help  define  the  task  needs  of  future  users. 


Second,  with  a  human-centered  automation  philosophy  of  humans  and  automation  working 
cooperatively  to  achieve  common  objectives  (Billings,  1996),  we  used  a  rational  and  principled  method 
for  task  and  function  allocation  to  humans  and  automation,  in  support  of  the  role  re-alignment  needed 
in  the  future.  There  are  varied  techniques  and  models  of  human-automation  allocation  with  different 
strengths  and  weaknesses  (e.g.,  automating  as  much  as  possible  defines  the  role  of  the  human  by  what 
is  left  over  from  the  automation  rather  than  the  strengths  of  the  human).  We  developed  and  employed 
novel  techniques  to  enable  SMEs  to  contribute  their  domain,  task,  and  technology  expertise  to  inform 
human-automation  allocation.  Additionally,  we  developed  and  used  novel  methods  to  define  effective 
information  exchanges  between  humans  and  automation  (Klein,  Woods,  Bradshaw,  Hoffman,  & 
Feltovich,  2004). 
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Third,  the  user-  and  task-centered  nature  of  our  approach  appropriately  directs  the  focus  onto 
immutable  needs  of  the  user,  and  not  the  technology  or  the  idiosyncrasies  of  a  particular  platform.  Since 
future  systems  will  grow  out  of  existing  systems,  it  is  crucial  to  understand  which  aspects  of  today's 
systems  and  HMIs  are  viable  for  the  future,  and  which  should  be  re-evaluated.  Here,  today's  systems 
were  assessed  against  users'  task  needs  to  begin  to  assess  which  unmanned  vehicle  "display  metaphors" 
and  features  remain  viable  and  which  should  be  abandoned.  Although  the  capabilities  of  future 
autonomous  vehicles  will  improve  vastly,  the  same  cannot  be  said  for  the  capabilities  of  future  human 
supervisors.  Those  supervisors  will  possess  the  same  perceptual  and  cognitive  processing  faculties  as 
today's  unmanned  vehicle  operators.  They  will  have  the  same  attentional  limitations  and  bottlenecks 
(Simons  &  Rensink,  2005)  and  limited  memory  capacity  that  requires  context  and  association  in  order  to 
function  (Anderson,  1983),  and  exhibit  the  same  serial,  slow  goal-directed  problem  solving  behaviors 
(Newell  &  Simon,  1972).  A  key  element  of  our  UCD  process  is  matching  the  design  of  the  tools  and  HMIs 
to  the  abilities  of  humans  through  the  careful  application  of  scientific  concepts  and  lessons  learned  in 
other  application  domains. 

The  unmanned  vehicle  and  systems  domain  is  vast  and  complex.  There  are  many  research  efforts 
currently  underway  tackling  different  aspects  of  achieving  the  future  DoD  vision  for  autonomy.  We 
scoped  our  cognitive  engineering  efforts  to  focus  on  tasks  related  to  monitoring  and  problem  detection, 
given  that  those  tasks  are  the  most  complex  aspects  of  supervisory  control  (Sheridan,  2006),  and  that 
future  users  will  become  monitors  of  automation  and  situations,  responsible  for  keeping  automation  in 
check  and  compensating  for  automation's  limitations. 

Interviews  with  unmanned  vehicle  experts  were  sequenced  across  multiple  SME  groups  and  sites,  with 
interview  stages  designated  for  each  SME  group  for  efficiency.  Given  the  time  limitations  of  the  SMEs, 
the  interviews  were  carefully  designed  and  prepared  to  maximize  SME  feedback  and  minimize  intrusion. 
Novel  approaches  were  developed  and  employed  to  provide  an  objective  basis  for  SMEs  to  share  their 
expectations  for  future  automation  and  to  facilitate  translating  the  task  analysis  results  to  actual  design. 

Prior  work  has  described  various  aspects  of  current  unmanned  aerial  vehicle  (UAV)  practice  by  user  role 
(Cooke,  Rivera,  Shope,  &  Caukwell,  1999;  Gugerty,  2004;  Nehme,  Crandall,  &  Cummings,  2007)  and 
begun  to  analyze  aspects  of  control  of  groups  of  vehicles  (e.g.,  Cummings,  Bruni,  Mercier,  &  Mitchell, 
2007;  Drury  &  Scott,  2008;  Nehme,  Scott,  Cummings,  &.  Furusho,  2006;  Scott  &  Cummings,  2006). 
However,  there  have  not  been  detailed  prescriptive  task  models  created  that  address  the  issue  of  how 
to  aggregate  and  rationalize  those  roles  for  the  future  supervisor  and  how  to  incorporate  SME 
expectations  of  future  roles  and  automation.  Our  approach  is  unique  in  creating  this  prescriptive  model 
through  capturing  current  user  expectations  for  future  automation  and  its  integration,  through  a  novel 
staged  and  sequential  UCD  approach.  The  design  artifacts  resulting  from  this  work  inform  initial 
prototype  concepts  reported  elsewhere  (see  Smallman  &  Cook,  2013). 

Materials,  Method,  and  Results 

Cognitive  Engineering  and  Analysis  Approach  and  Process 

Within  our  tailored  UCD  process,  we  conducted  a  staged  task  analysis  to  define  the  task  needs  for  future 
autonomous  system  supervision  through  interviews  with  present-day  unmanned  vehicle  domain 
experts.  There  are  many  approaches  to  conducting  task  analysis,  a  multitude  of  methods  for  conducting 
it,  and  a  variety  of  outcomes,  design  artifacts,  and  products  resulting  from  it  (see  Diaper  &  Stanton, 
2004,  for  a  review).  The  selection  of  which  approach  and  method  to  use  depends  on  several  factors, 
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including  the  goals  of  the  analysis,  the  design  artifacts  needed,  and  the  stakeholders  involved  in  the 
process.  The  approach  used  in  this  effort  synthesized  elements  from  multiple  methods  to  achieve  the 
goals  of  the  analysis  and  design. 

The  task  analysis  was  conducted  using  the  following  staged  interview  approach  with  a  broad, 
representative  sample  of  unmanned  systems  SMEs,  sequenced  over  time  and  across  different  military 
and  commercial  industry  sites,  to  produce  specific  design  artifacts.  It  focused  on  the  three  steps  shown 
in  color  in  Figure  2.  A  key  design  artifact  produced  was  a  taxonomy  of  roles  and  tasks  for  unmanned 
system  operation  and  supervision.  Figure  3  shows  a  thumbnail  sketch  of  which  parts  of  the  role-task 
taxonomy  each  stage  focused  on. 


Stage  1:  Define  core  tasks  involved  in  unmanned  vehicle  /  system  operation  and  supervision 

•  Process:  Generated  role-task  matrix  for  core  unmanned  system  user  roles  and  tasks  performed 
during  mission  execution.  Reviewed  and  revised  role-task  matrix  with  unmanned  vehicle  SMEs. 

•  Rationale:  Center  interventions  around  users'  tasks.  Scope  design  effort  around  core  tasks 
performed  during  mission  execution. 

•  SMEs:  One  unmanned  maritime  domain  SME  and  five  SMEs  from  a  military  controlled  testing 
venue  for  unmanned  vehicles. 

•  Design  artifact:  role-task  matrix  (Figure  5). 

Stage  2:  Specify  current  (descriptive)  allocation  of  tasks  to  humans  and  automation,  and  propose 
future  (prescriptive)  allocation 

•  Process:  Specified  current  and  proposed  future  allocation  of  tasks  in  Stage  1  role-task  matrix  to 
humans  and  automation  through  SME  involvement.  Used  innovative  approach  to  involve  SMEs 
in  task  allocation,  expanding  on  approach  developed  for  system  designers  (Parasuraman, 
Sheridan,  &  Wickens,  2000). 
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•  Rationale:  Define  starting  point  to  build  from  to  achieve  future  vision.  Understand  extent  of  gap 
to  bridge  between  today  and  future.  Inform  task  allocation  based  on  strengths/limits  of  humans 
and  automation  and  user  task  needs.  Inform  algorithm  development. 

•  SMEs:  13  SMEs  from  a  leading  commercial  provider  of  high-performance  UAS. 

•  Design  artifact:  role-task  matrix  with  descriptive  and  prescriptive  task  allocation  (Figure  5). 

Stage  3:  Specify  information  exchange  between  humans  and  automation  for  subset  of  detection  tasks 

•  Process:  Generated  key  information  inputs  and  outputs  for  human-automation  information 
exchanges  for  a  subset  of  detection  tasks  from  Stage  2  prescriptive  role-task  matrix.  Reviewed 
and  revised  key  information  inputs  and  outputs  with  unmanned  systems  SMEs.  Employed  novel 
procedure  to  involve  SMEs  in  design-critical  decisions  for  information  access  and  level  of  detail. 

•  Rationale:  Support  user  information  exchanges  with  automation.  Facilitate  user  trust  and  insight 
into  automation.  Facilitate  mapping  from  results  to  design. 

•  SMEs:  Eight  SMEs  from  a  major  US  Air  Force  UAS  training  facility. 

•  Design  artifact:  information  inputs  and  outputs  for  human-automation  exchanges. 
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T1  military  and  civilian  unmanned  systems  experts  experienced  in  vehicle  control,  sensor  control, 
and  mission  command  on  a  range  of  unmanned  vehicle  platforms  (DoD  UAS  Group  1-5)  for 
missions  ranging  from  operational  tests  through  theater  operations. 


Figure  4.  Summary  of  SME  participant  characteristics. 


Participants 

A  total  of  27  domain  experts  from  four  unmanned  systems-related  groups  were  interviewed  over  four 
months  in  2012.  Different  types  of  unmanned  vehicle  SMEs  were  selected  to  yield  a  sampling  of  users 
with  experience  across  vehicles,  mission  types,  and  team  configurations,  in  both  the  military  and 
industry.  Details  of  participant  characteristics  are  summarized  in  Figure  4. 
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Sites 

SMEs  from  four  groups  were  recruited:  1)  a  Fleet  Forces  Command-sponsored  annual  Navy  exercise,  2)  a 
military  controlled  testing  venue  for  unmanned  vehicles,  3)  a  leading  commercial  UAS  provider,  and  4)  a 
major  US  Air  Force  UAS  training  facility.  Across  sites,  the  SMEs  were  universally  motivated  and 
interested  in  improving  the  operation  and  safety  of  unmanned  and  future  autonomous  systems  and 
having  the  opportunity  to  impact  design  and  development. 

Platforms 

SMEs  had  experience  with  unmanned  maritime  craft  and  unmanned  aerial  systems,  including  an  array  of 
DoD  Group  1-5  UAS;  platforms  included  Sea  Fox,  Mako,  TigerShark,  Arrow,  Aerosonde,  ScanEagle, 
Predator  (MQ-1),  and  Reaper  (MQ-9). 

Experience 

Twenty-six  of  the  SMEs  were  experienced  in  one  or  more  of  the  roles  of  vehicle  operator,  sensor 
operator,  and  mission  commander.  In  total,  22  had  experience  as  vehicle  operator,  19  as  sensor 
operator,  and  11  as  mission  commander.  One  additional  SME  with  expertise  in  unmanned  maritime 
vehicles,  CONOPS,  and  Navy  fleet  exercise-based  testing  also  participated.  All  SMEs  reported  their 
experience  level  as  intermediate  or  expert,  with  a  range  of  1-14  years  of  experience  across  platforms. 

Materials  and  Method  -  General 

The  interviews  and  site  visits  were  designed  and  scoped  to  support  the  three  task  analysis  stages 
described  earlier  and  shown  in  Figure  3.  With  the  exception  of  some  minor  variations  due  to  scheduling 
and  availability,  the  same  general  interview  procedure  was  used  across  all  sites.  We  approached  and 
made  formal  requests  to  several  unmanned  vehicle  sites  and  groups  with  potential  SMEs  with  a  range  of 
experience.  Since  all  SME  participation  was  voluntary  and  un-paid,  several  measures  were  taken  to 
minimize  the  time  burden  to  the  SMEs  and  their  daily  routines  while  maximizing  the  feedback  gained 
from  the  SMEs  during  the  interviews. 

Each  interview  session  consisted  of  two  scientist  interviewers  and  one  or  two  SMEs.  The  SMEs  were 
informed  of  the  institutional  review  board  (IRB)  approval  of  the  study  and  the  voluntary  nature  of  their 
participation  at  the  start  of  the  session.  Care  was  taken  to  explain  the  purpose  of  the  effort,  the 
criticality  of  SME  involvement  in  the  design  process,  and  the  potential  benefits  and  payoffs  for  users. 
The  goal  of  designing  automation  as  a  peer  or  assistant  to,  rather  than  a  replacement  of,  human 
performance  was  stressed.  After  obtaining  informed  consent,  general  information  about  each  SME's 
background  and  experience  with  unmanned  vehicles  was  collected.  Each  set  of  materials  was  tailored 
to  each  task  analysis  stage.  The  interview  materials  served  to  structure  and  direct  the  interview 
discussions  and  provide  the  context  necessary  for  soliciting  the  SME  knowledge  and  expertise  needed 
(Cooke,  1999).  The  interviews  were  highly  interactive,  with  SMEs  reviewing,  commenting  on,  and 
helping  to  refine  the  interview  materials,  providing  elaborating  examples  when  necessary. 

Site  visits  also  included  tours  of  the  facilities  and  ground  control  stations  (GCS),  observations  of  live 
training  exercises,  hands-on  access  to  UAS  simulators  and  HMIs,  and  viewing  the  unmanned  vehicles  on 
the  flight  line  and  parked  in  hangars.  SMEs  and  key  personnel  were  thanked  for  their  participation  at  the 
end  of  the  interview  sessions  and  site  visits.  Some  SMEs  who  offered  to  provide  additional  feedback  and 
clarification  were  contacted  with  follow-up  questions. 
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Materials,  Method,  and  Results  -  Stage  1 

Defining  Core  Tasks  in  Unmanned  Vehicle  Operation  and  Supervision  during  Mission  Execution 

The  goal  of  the  first  task  analysis  stage  was  to  codify  and  analyze  the  core  tasks  of  unmanned  vehicle 
operation,  capturing  the  general  cognitive  and  perceptual  challenges  in  monitoring  and  assessing 
information  during  mission  execution  (vs.  system-specific  control  tasks).  The  scope  of  the  task  analysis 
was  on  monitoring  and  assessment  tasks.  Planning,  takeoff,  platform-specific  control,  landing,  and 
recovery-related  tasks  were  outside  the  scope  of  interest. 

Stage  1  materials  were  drafted  prior  to  the  interviews  to  maximize  the  efficiency,  focus,  and  value  of  the 
time-limited  interviews  with  SMEs.  These  materials  consisted  of  a  set  of  draft  tasks,  organized  by  roles  in 
a  "role-task  matrix"  (Spillers,  2004).  The  draft  role-task  matrix  was  informed  by  a  review  of  previous  task 
analyses  in  the  unmanned  systems  and  related  domains,  and  relevant  operational  doctrine  and  concepts 
of  operations  (e.g.,  Cook  &  Smallman,  2010;  Fleet  Forces  Command,  2008;  Gugerty,  2004;  Nehme, 
Crandall,  &  Cummings,  2007;  OSD,  2012;  Sibley  &  Coyne,  2012).  Generally,  roles  are  collections  of  tasks 
to  perform  a  specific  function.  Decomposition  into  roles  and  tasks  is  a  standard  technique  with  useful 
application  to  both  software  development  and  HMI  design  within  a  UCD  approach  (e.g.,  Osga,  2006). 
Organizing  tasks  by  roles  has  several  advantages:  Roles  allow  tasks  to  be  clustered  into  meaningful 
chunks  as  a  basis  for  assignment,  provide  a  means  to  map  work  onto  any  team  configuration  (current  or 
future,  human  and  automation),  and  suggest  ways  to  organize  HMIs  that  support  users  taking  distinct 
roles  (Smallman,  Cook,  Beer,  &  Lacson,  2009). 

A  single  individual  can  perform  one  or  more  roles.  Each  role  for  current  unmanned  vehicle  operation— 
vehicle  operator,  sensor/payload  operator,  and  mission  commander— is  often  assumed  by  a  single 
individual,  though  one  person  takes  on  more  than  one  role  in  some  team  configurations  (e.g.,  one 
person  serving  as  vehicle  and  sensor  operator).  The  future  supervisor  and  supporting  automation  will  be 
expected  to  take  on  the  multiple  roles  currently  assumed  today  by  multiple  individuals. 

Figure  5  shows  the  content  of  the  core  role-task  matrix.  Current  (and  future)  roles  are  specified  in  rows. 
Task  groups  of  monitor,  detect,  assess,  and  decide  are  shown  in  columns.  Specific  tasks  are  listed  in  each 
cell  created  by  the  intersection  of  role  rows  and  task  group  columns.  Task  group  columns  are  ordered 
roughly  in  the  sequence  they  are  performed;  for  example,  monitor  the  vehicle  to  detect  anomalies  or 
problems,  and  assess  the  ability  or  need  to  fix  the  problem,  to  help  decide  which  course  of  action  to 
pursue.  Within  a  role  row,  similar  tasks  are  grouped  together  (e.g.,  the  vehicle  operator  tasks  include 
monitoring  the  vehicle,  and  the  environment).  Each  task  phrase  is  constructed  by  combining  the  column 
header  with  the  bulleted  task  beneath  (e.g.,  Detect  ongoing  or  anticipated  anomalies  or  problems  with 
vehicle  health  and  status...").  These  task  groups  align  roughly  with  a  classic  four-stage  view  of 
information  processing  (Parasuraman  et  al.,  2000)  and  this  decomposition  allows  us  to  develop  targeted 
support  for  these  tasks,  and  anticipate  where  weaknesses  will  arise. 
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i  a  new  or  related  target 


■  Fully 
Human 


Human 

Delegated 


Human 

Supervised 


Nearly 

Autonomous 


Fully 

Autonomous 


Figure  5.  Stage  1  role-task  matrix,  with  Stage  2  descriptive  (current)  and  prescriptive  (future)  task  allocation. 
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To  reflect  the  core  goals  of  unmanned  systems  operation  and  the  satisficing  rather  than  optimizing  goal 
that  often  currently  prevails,  tasks  were  focused  on  detecting  and  responding  to  problems  or  changes 
("detect  ongoing  or  anticipated  problems  with  collection  quality")  rather  than  just  generally  monitoring 
situations  ("monitor  collection  quality").  This  focus  on  detecting  and  responding  to  problems  or  changes 
has  been  validated  throughout  the  SME  interviews:  although  operators  do  monitor  (collection)  quality, 
their  goal  is  to  ensure  it  stays  above  a  particular  level,  and  any  deviations  from  this  are  indicators  that 
(collection)  quality  is  or  will  become  sub-standard.  Additionally,  this  focus  on  detecting  ongoing  or 
anticipated  problems  reflects  the  goals  of  operators  to  both  monitor  proactively  and  to  respond  to 
changes  that  arise. 

The  tasks  were  deliberately  general,  high  level,  and  phrased  in  terms  of  achieving  a  particular  goal 
(avoiding  limitations  due  to  platform  specificity).  For  example,  "Detect  ongoing  or  anticipated  anomalies 
or  problems  in  vehicle  health  and  status"  is  general  enough  to  pertain  to  detecting  out-of-range 
indicator  values  caused  by  malfunctions  or  environmental  conditions  for  any  number  of  different 
unmanned  platforms.  Operators  today  are  responsible  for  detecting  these  anomalies  or  problems  by 
directly  monitoring  the  vehicle  indicator  values  (engine  oil  level,  temperature,  pressure,  RPMs,  etc). 
Future  users  are  likely  to  off-load  some  of  that  data  monitoring  to  automation,  and  instead  focus  their 
efforts  on  ensuring  the  automated  monitors  themselves  are  in  check. 

The  draft  role-task  matrix  was  initially  created  with  sticky  notes  on  butcher  paper  to  keep  it  agile  and 
flexible  as  we  reviewed  and  refined  it  with  SMEs,  and  to  deliberately  convey  to  the  SMEs  how  open  it 
was  to  their  feedback  and  rearrangement.  Information  used  or  needed  for  the  tasks  was  listed  at  the 
bottom  in  the  draft  version.  The  draft  role-task  matrix  went  through  two  reviews  and  revisions,  first  with 
the  unmanned  maritime  vehicle  SME  by  telecon,  and  second  with  five  SMEs  from  the  military  controlled 
testing  venue.  Feedback  consisted  of  additions,  deletions,  modifications,  and  clarifications  in  content, 
wording,  and  task  placement.  Following  these  sessions,  the  role-task  matrix  was  revised  and  translated 
into  a  digital  format  (Figure  5).  This  revised  role-task  matrix  was  used  as  the  basis  for  the  descriptive  and 
prescriptive  task  models,  described  next.  Figure  5  shows  both  the  role-task  matrix  and  the  color-coded 
results  of  the  SME  allocation  of  tasks  to  humans  and  automation  from  Stage  2. 

Materials  and  Method  -  Stage  2 

Descriptive  (Current)  and  Prescriptive  (Future)  Allocation  of  Tasks  to  Humans  and  Automation 

The  goals  of  Stage  2  were  to  (1)  specify  the  allocation  of  tasks  to  humans  and  automation  in  current 
practice  (descriptive)  and  (2)  propose  a  task  allocation  scheme  for  future  practice  (prescriptive).  The 
role-task  matrix  developed  in  Stage  1  was  used  as  the  basis  for  the  descriptive  and  prescriptive 
assignments.  A  group  of  13  SMEs  from  a  leading  commercial  UAS  provider  contributed  input  for  the 
descriptive  and  prescriptive  task  assignments. 

A  vocabulary  and  systematic  yet  simple  method  was  needed  for  SMEs  to  communicate  and  classify  the 
descriptive  and  prescriptive  allocation  of  tasks  to  automation  and  humans.  For  this,  a  simple  rating  scale 
was  developed,  leveraging  from  existing  automation  scales  from  the  supervisory  control  literature  and 
operational  documentation  (e.g.,  DoD,  2011;  Parasuraman  et  al.,  2000;  Sheridan  &  Verplank,  1978). 

For  simplicity,  this  scale  consisted  of  five  task  allocation  categories  ranging  from  fully  human  to  fully 
autonomous.  Each  category  specified  the  roles  of  both  the  human  and  the  automation,  describing  their 
relative  functions,  authority,  and  relationship.  This  conveyed  the  importance  of  the  joint  human- 
automation  relationship  in  creating  a  joint  cognitive  system  (Woods  &  Hollnagel,  2006).  This  approach 
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was  intended  to  avoid  the  shortfalls  of  other  methods  that  have  focused  disproportionally  on  the 
automation  and  technology,  conceptualized  of  autonomy  as  simple  delegation  of  a  complete  task  to  a 
computer,  or  treated  automation  as  operating  at  discrete  and  rigid  levels  (DoD,  2012). 


Figure  6.  Task  allocation  scale  and  categories  for  Stage  2. 


The  task  allocation  procedure  was  introduced  incrementally  to  SMEs  by  covering  the  concepts  in  Figure 
6  from  top  to  bottom.  First,  some  basic  examples  of  the  relative  strengths  of  humans  and  automation 
were  described,  inspired  by  Fitts'  classic  list  (1951).  Next,  the  task  allocation  scale  and  the  description  of 
each  category  were  reviewed.  To  make  the  categories  meaningful  to  all  SMEs,  they  were  grounded  in 
the  increasingly  popular  automated  grocery  store  checkout  systems.  Associated  examples  of  futuristic 
automation  assisting  with  scanning  and  tallying  groceries  were  mapped  to  the  categories.  Generic 
tradeoffs  in  speed,  accuracy,  and  customer  service  listed  beneath  the  grocery  store  example  in  Figure  6 
were  discussed.  The  everyday  example  was  used  to  encourage  the  SMEs  to  learn  the  task  allocation 
concept  rather  than  focus  on  specific  details  of  unmanned  vehicle  technologies  and  capabilities. 

Next,  to  help  the  SMEs  begin  to  think  about  the  task  allocation  concept  in  terms  of  unmanned  vehicle 
tasks,  a  vehicle  operator  task  was  mapped  to  the  task  allocation  categories.  The  example  task  was 
"detect  ongoing  or  anticipated  anomalies  or  problems  with  vehicle  health  and  status"  and  the  specific 
example  mapping  was  as  follows: 

•  User  monitors  vehicle  health  and  status  and  is  responsible  for  detecting  all  out  of  range  values  or 
problems  (1  -  Fully  human) 

For  2-5,  "detection"  automation  helps  to  monitor  the  health  and  status  of  the  vehicle  and: 

•  alerts  the  user  to  all  out  of  range  values;  user  must  review  all  alerts  and  decide  which  ones  warrant 
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attention  and  which  to  dismiss  (2  -  Human  delegated) 

•  alerts  the  user  to  a  subset  of  out  of  range  values,  for  the  user  to  review  and  approve  or  dismiss 
(similar  to  "management  by  consent")  (3  -  Human  supervised) 

•  decides  on  the  subset  of  out  of  range  values  of  concern;  the  user  can  dismiss  alerts  within  a  given 
time  period  (similar  to  "management  by  exception")  (4  -  Nearly  autonomous) 

•  decides  on  the  subset  of  out  of  range  values  of  concern;  the  user  has  no  ability  to  review  or  dismiss 
(5  -  Fully  autonomous) 

The  essence  of  this  allocation  activity  was  indicating  how  a  task  could  be  performed  by  users  and 
automation  to  varying  degrees.  For  example,  detecting  anomalies  can  be  done  completely  by  a  user  or 
can  be  assisted  to  varying  degrees  by  some  detection  automation  that  the  user  reviews,  approves, 
rejects,  or  takes  no  part  in.  Similarly,  assessing  whether  an  anomaly  can  and  should  be  fixed  can  be  done 
completely  by  a  user,  or  can  be  assisted  by  some  assessment  automation  that  the  user  reviews, 
approves,  rejects,  or  takes  no  part  in. 

To  perform  the  descriptive  and  prescriptive  task  allocation,  SMEs  were  provided  with  large  printouts  of 
the  core  role-task  matrix  from  Stage  1  (the  text  only  in  Figure  5),  and  used  colored  highlighters  matching 
the  colors  of  the  allocation  categories  in  Figure  6  to  simply  allocate  tasks  to  the  categories. 

For  the  descriptive  allocation,  SMEs  approximated  the  current  allocation  of  tasks  to  humans  and 
automation.  For  the  prescriptive  allocation,  SMEs  were  asked  to  indicate  the  ideal  allocation  of  tasks  to 
the  future  autonomous  system  supervisor  and  future  automation.  SMEs  were  asked  to  assume  a  future 
vision  (approximately  20  years  in  the  future)  in  which  a  single  person  will  manage  multiple  unmanned 
vehicles  across  multiple  missions,  with  dramatically  improved  and  expanded  automation  enabling  this 
multi-vehicle  and  multi-mission  capability.  The  user's  job  will  be  to  manage  this  improved  automation 
that  will  take  on  aspects  of  the  functions  that  are  currently  handled  primarily  by  humans.  Concrete 
examples  of  tasks  for  which  some  automation  is  available  or  under  development  today  were  provided  to 
help  SMEs  envision  the  types  of  tasks  that  automation  might  be  available  to  support  in  the  future. 
Examples  included  route  re-planning,  change  detection,  anomaly  detection,  collision  and  terrain 
avoidance,  target  tracking,  and  vehicle  coordination. 

It  was  further  explained  that  SMEs  should  think  of  the  prescriptive  task  allocation  as  being  flexible  and 
adaptive  as  opposed  to  rigid  (Rouse,  1988;  Scerbo,  1996),  which  will  be  especially  important  in  the 
dynamic  and  unpredictable  environments  of  the  future.  We  explained  that  even  with  this  improved 
automation,  a  human  supervisor  will  always  be  critical:  events  will  unfold  and  issues  will  arise  that  will 
be  beyond  the  scope  of  what  even  the  best  automation  will  be  able  to  handle,  and  will  require  the 
monitoring,  intervention,  and  judgment  that  only  a  human  can  provide.  We  reminded  SMEs  of  the 
human-centered  approach  of  this  research,  advocating  that  future  automation  assists  rather  than 
replaces  human  performance  (Wickens  &  Flollands,  2000).  We  acknowledged  the  challenges  of 
imagining  this  future  vision  with  all  of  the  assumed  advancements  in  automation. 

To  aid  in  assigning  the  prescriptive  task  allocation  categories,  we  provided  SMEs  with  a  set  of  criteria  to 
use  as  an  objective  basis  and  a  rationale  for  future  automation  allocation.  The  criteria  (summarized  at 
the  bottom  of  Figure  6)  were: 

•  Knowledge  /  experience:  Task  does/does  not  require  application  of  long  term  knowledge 

•  Context  sensitivity:  Task  entails  a  procedure  with  context-dependent/independent  rules 
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•  Workload  /  processing  capacity:  Task  allows  focus  on  single  issue  at  a  time  vs.  requires  parallel 
processing  of  large  data  sets  and  multiple  issues 

•  Consequences:  Consequences  of  failing  are  serious  (death,  injury)  vs.  minor 

These  criteria  are  related  to  the  evaluative  criteria  for  automation  design  developed  by  Parasuraman  et 
al.,  (2000).  Our  methodology  provided  a  novel  way  of  adapting  these  criteria,  intended  for  use  by  system 
designers,  to  harness  domain  expertise  and  input  from  unmanned  vehicle  SMEs  to  inform  future  task 
allocation  tailored  to  the  unique  requirements  and  nuances  of  the  autonomous  systems  domain.  SMEs 
assigned  prescriptive  task  allocation  categories  using  the  colored  highlighters,  and  used  the  assignment 
criteria  above  as  a  basis  for  their  categorizations.  The  criteria  were  not  strictly  tied  to  the  allocation 
categories,  but  helped  guide  the  direction  of  the  SME  assignments  to  categories. 

For  both  the  descriptive  and  prescriptive  allocation  activities,  responses  were  discussed  as  a  group. 
Results  color-coded  by  SME  responses  are  presented  in  Figure  5. 

Stage  2:  Results 

The  color  coding  of  the  descriptive  and  prescriptive  role-task  matrix  reveals  key  patterns  and  differences 
across  the  two  models.  For  the  descriptive  role-task  matrix,  SMEs  classified  the  vast  majority  of  current- 
day  tasks  as  fully  human  (predominance  of  red  color  coding  in  the  "current"  columns  of  Figure  5).  For 
the  vehicle  operator  and  sensor  operator,  some  tasks  were  classified  as  human  delegated  (e.g.,  binning 
data  into  alert  categories),  and  a  small  subset  as  autonomous  (e.g.,  sensor  stabilization  functions,  scan 
mode).  All  current  mission  commander  tasks  were  classified  as  fully  human.  SMEs  attempted  to  assign 
categories  based  on  the  current  state  of  automation  in  unmanned  aerial  systems  generally  (as  the 
current  state  of  automation  varies  somewhat  across  platforms). 

These  SME  classifications  of  relatively  low  automation  support  are  echoed  by  recent  findings  by  the 
Defense  Science  Board  (DoD,  2012)  that  existing  and  proven  autonomous  capabilities  are  being 
generally  underutilized  in  today's  unmanned  systems.  Proven  technologies  are  underutilized  in  vehicle 
fault  detection  and  management,  communications  management,  mission  planning  and  decision  support, 
and  contingency  planning. 

How  well  are  today's  HMIs,  systems,  and  available  automation  supporting  the  task  needs  of  today's 
users  specified  in  Figure  5?  Figure  7  provides  a  summary  level  assessment  of  the  current  state  of  task 
support,  highlighting  specific  issues  with  monitor,  detect,  assess,  and  decide  to  tie  back  to  the  role-task 
matrix.  Many  of  the  HMI  and  human  factors-related  issues  in  unmanned  systems  identified  in  reports 
from  almost  10  years  ago  (e.g.,  Tvaryanas,  2004;  Williams,  2004)  are  still  seen  in  the  systems  and  HMIs 
of  today.  A  common  theme  that  emerged  throughout  the  interviews  was  the  burden  and  challenge  for 
users  to  manage  and  compensate  for  these  shortfalls  (e.g.,  "It  feels  like  90%  of  our  training  involves 
developing  and  teaching  work-arounds  to  get  the  system  to  do  what  we  need...").  Work-arounds  that 
current  operators  devise,  teach,  and  employ  include  using  dry-erase  marker  annotations  (marked 
directly  on  HMI  screens)  to  flag  and  draw  attention  to  key  indicators  and  to  record  starting  values  as 
comparisons  for  real-time  values  to  help  monitor.  These  work-arounds  are  strikingly  similar  to  strategies 
used  by  nuclear  plant  operators  when  monitoring  (Mumaw,  Roth,  Vicente,  &  Burns,  2000).  The 
development  and  use  of  these  strategies  is  indicative  of  the  shortfalls  of  systems  in  both  domains. 

Compared  to  the  descriptive  model  with/u//y  human  and  human  delegated  indicated  for  most  tasks,  the 
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prescriptive  model  assumes  more  allocation  to  automation,  and  specifies  allocation  across  the  full  range 
of  categories  (see  "future"  columns  in  Figure  5).  SMEs  envision  automation  helping  significantly  with 
detection  and  assessment  tasks  for  vehicle  and  sensor  operators.  The  variations  in  task  allocation 
categories  across  the  "detect"  tasks  mainly  reflect  differences  in  management  authority  for  handling  the 
detections  (consent  vs.  exception  vs.  independent)  before  being  passed  on  to  a  human  or  other 
automation  at  the  next  step.  SMEs  anticipated  needing  more  human  involvement  for  tasks  related  to 
deciding  on  courses  of  action,  as  well  as  many  of  the  mission  commander  tasks  which  tend  to  be  more 
complex  (e.g.,  detect  events  impacting  or  likely  to  impact  customer  satisfaction).  SMEs  also  envisioned 
needing  more  human  involvement  or  approval  as  the  criticality  of  mission  events  increases. 


Inconsistencies  in  coding  and 
meaning  across  HMIs  and  platforms 

•  Cross-platform  transfer  minimized  due  to 
different  HMIs  for  different  platforms 

•  Inconsistent  use  of  visual  features  (e.g., 
color)  within  and  across  systems 


Inadequate  attention  management  support 
(for  monitor  and  detect ) 

•  Poor  support  for  monitoring  and  comprehension  of 
changes  over  time,  and  proactive  monitoring 

•  Serial,  continuous,  reactive  monitoring  stance 

•  Users  burdened  to  determine  and  focus  on  what  is 
task-relevant,  and  filter  out  the  task-irrelevant 


ction  and  task  complexity 

•  Simple  functions  and  tasks  require 
memorization  and  training  of 
complex,  multi-step  procedures 

•  Training  focused  on  compensating 
for  HMI  shortfalls  detracts  from 
teaching  core  objectives 


Insufficient  decision  support  (for 
assess  and  decide ) 

•  User  burdened  to  find,  mentally  integrate, 
and  transform  data  into  decision  level 
information 

•  Uninformative  and  context-/nsensitive  alerts 


Representative  HMIs 


Inadequate  support  from  automation 

•  Lack  of  transparency  into  automation,  mode, 
authority 

•  Underutilization  of  automation  in  systems 


Figure  7.  Overview  of  shortfalls  of  current  unmanned  system  HMIs  and  automation. 


This  role-task  matrix  covers  a  wide  range  of  tasks  for  which  future  decision  support  can  be  developed. 
How  can  the  matrix  and  the  SME  assessments  be  used  to  guide  the  design  of  decision  support  for  future 
autonomous  systems  supervisors?  We  envision  the  prescriptive  role-task  matrix  as  a  helpful  tool  for 
scoping  the  type  of  task  support  needed  for  a  wide  range  of  future  supervision  tasks,  as  an  initial  step  in 
the  design  of  joint  human-autonomous  system  decision  support.  The  prescriptive  allocations  suggest  a 
general  human-automation  interaction  scheme  for  core  tasks  as  a  guide  and  useful  starting  point  to 
enable  designers  to  achieve  robust  designs. 


Following  Stage  2,  we  used  the  role-task  matrix  to  inform  the  development  of  decision  support  for  a 
subset  of  tasks  related  to  problem  detection  for  vehicles,  environments,  and  sensors  (see  orange  focus 
region  in  Figure  3).  We  chose  to  focus  on  the  problem  detection  tasks  because  SMEs  saw  significant 
potential  for  assistance  from  automation  for  these  kinds  of  detection  tasks  (see  Figure  5),  and  several 
efforts  are  underway  to  develop  and  mature  anomaly  and  problem  detection  automation.  As  outlined  in 
Figure  2,  we  began  by  defining  the  workflow  for  these  detection  tasks,  and  specifying  the  necessary 
supporting  information  exchanges  needed  for  users  and  automation  to  jointly  perform  these  detection 
tasks.  The  workflow  is  shown  below  in  Figure  8,  followed  by  a  brief  description  of  the  method  we  used 
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to  define  information  exchanges  with  SMEs. 

Stage  3:  Approach  to  Defining  Workflow  and  Information  Exchanges 

Anomaly  detection  tasks  lend  themselves  to  assistance  from  automation,  assuming  normal  performance 
and  deviations  from  normal  can  be  defined.  Detection  technologies  are  currently  used  to  detect 
changes,  problems,  and  anomalies  in  several  work  domains,  including  industrial  process  control  and 
medicine.  There  is  significant  potential  for  these  technologies  to  assist  within  unmanned  systems,  as 
highlighted  by  SMEs  in  their  Stage  2  assessments.  In  this  section,  we  provide  an  overview  of  how  the 
Stage  2  assessments  are  being  harnessed  to  concretely  define  HMI  concepts  for  anomaly  detection. 

We  began  by  specifying  how  tasks  in  the  role-task  matrix  related  to  problem  detection  are  currently 
performed  by  humans  and  automation,  and  how  they  should  be  performed  in  the  future.  We 
characterized  monitoring  and  detection  by  sequencing  their  associated  tasks  into  the  workflows  shown 
in  Figure  8.  We  contrasted  future  practice  (Figure  8,  right),  based  on  the  prescriptive  role-task  matrix 
and  ideal  task  support,  with  current  practice  (Figure  8,  left),  based  on  the  descriptive  role-task  matrix 
and  task  support  and  deficiencies  of  current  systems  (see  Figure  7).  These  workflows  are  also  informed 
in  part  by  interviews  with  industrial  process  control  operators  who  monitor  and  supervise  complex 
automation  through  information  displays  (Smallman  &  Cook,  2013).  The  relative  strengths  and 
weaknesses  of  the  two  approaches  in  Figure  8  are  discussed  in  detail  in  Smallman  and  Cook  (2013). 

Current  problem  detection  is  characterized  by  its  reactivity,  due  to  the  practice  of  responding  to  system 
alerts,  and  diagnosing  and  addressing  problems  after  they  have  surfaced.  Anomaly  detection  does  exist 
in  today's  unmanned  systems  but  only  in  rudimentary  form,  manifesting  as  alerts  for  a  limited  set  of 
vehicle  and  sensor  health  and  status  indicators.  These  alerts  tend  to  be  uninformative,  un-prioritized, 
insensitive  to  and  lacking  in  context,  and  based  on  a  limited  set  of  data.  Paradoxically,  the  relevant 
information  needed  to  interpret  and  prioritize  the  alerts  is  available  within  the  system,  but  is  not 
integrated  or  harnessed  for  effective  alerting  management.  Users  are  left  to  initiate  investigation  of 
underlying  causes,  urgency,  impact,  and  likely  resolution  (i.e.,  will  they  self-correct  or  not?). 

For  example,  current-day  MQ-9  Reaper  pilots  receive  "aircraft  not  close  to  assigned  altitude"  alerts  that 
can  be  triggered  by  different  causes  and  require  different  responses.  Pilots  must  investigate  several 
other  pieces  of  information  (on  separate  HMIs)  to  understand,  differentiate,  prioritize,  and  resolve  these 
altitude  alerts.  An  aircraft  in  "speed  preference  mode"  temporarily  disregards  altitude  and  will  self- 
correct  on  its  own,  but  an  alert  is  triggered  nonetheless;  however,  the  same  alert  could  be  triggered  for 
an  aircraft  whose  speed  lever  in  the  ground  control  station  is  not  fully  forward  (for  fuel  conservation) 
and  will  not  self-correct.  It  is  up  to  the  operator  to  investigate  and  differentiate  these  alerts. 

Proactive  monitoring  (shown  in  Figure  8,  right),  in  contrast,  stresses  spotting  deviations,  problems,  and 
anomalies  before  they  become  serious  problems  to  allow  time  for  diagnosis  and  intervention,  which  is 
critical  in  several  domains  including  industrial  process  control  (e.g..  Burns,  2006),  nuclear  plant 
monitoring  (e.g.,  Mumaw  et  al.,  2000),  and  unmanned  systems.  Today's  unmanned  vehicle  operators 
strive  to  monitor  proactively,  but  are  hindered  by  the  shortfalls  of  current  anomaly  detection  and  HMIs 
(Smallman  &  Cook,  2013).  Further,  the  information-dense,  multi-window,  real-time  status  displays 
typical  of  today's  operational  systems  intensify  these  problems,  further  overwhelming  users  when  they 
are  stressed  (e.g.,  Bransby,  2001).  For  example,  alarm  banners  show  status  and  anomalies,  but  lack 
context  for  anomaly  interpretation,  prioritization,  and  management. 
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Figure  8.  Elaborated  workflows  contrasting  reactive  and  proactive  monitoring  and  detection,  informed 
by  descriptive  and  prescriptive  role-task  matrix  (from  Smallman  &  Cook,  2013). 

Anomaly  detection  is  even  more  challenging  in  the  multi-vehicle,  multi-mission  situation  envisioned  for 
the  future.  The  number  of  detected  anomalies  is  likely  to  increase,  with  the  increase  in  vehicles  and 
missions,  potentially  flooding  the  future  supervisor  with  an  unmanageable  number  of  alerts  and  leading 
to  slow,  reactive  responding  (DoD,  2012;  Errington,  Reising,  &  Burns,  2009).  Human  cognitive  abilities 
are  relatively  fixed,  and  cannot  grow  to  accommodate  such  an  increase  in  loading  in  the  future.  If  not 
appropriately  designed  and  tailored  for  this  future  scenario,  anomaly  detection  technologies  have  the 
potential  to  increase  rather  than  decrease  workload,  worsen  rather  than  improve  performance,  and 
make  monitoring  and  detection  even  more  reactive  vs.  proactive.  The  results  of  the  future  anomaly 
detection  automation  must  be  presented  to  users  in  ways  that  help  them  quickly  review  and  understand 
the  results  and  prioritize  them. 

We  must  carefully  tailor  the  design  of  anomaly  detection  to  support  proactive  monitoring  in  the  future, 
and  avoid  these  potential  pitfalls.  To  begin  to  address  this,  we  focused  a  third  set  of  interviews  on 
identifying  (1)  what  information  such  anomaly  detectors  would  need  to  detect  anomalies,  and  (2)  what 
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information  users  would  need  to  know  about  the  results  of  the  anomaly  detection  to  effectively 
supervise  and  manage  it.  With  eight  SME  UAS  trainers  from  a  major  US  Air  Force  training  facility,  we 
reviewed  and  refined  a  set  of  information  inputs  that  need  to  be  considered  by  anomaly  detection 
automation,  to  help  inform  automation  and  algorithm  development,  and  the  necessary  information 
outputs  to  enable  a  user  to  understand  results  of  the  automation,  to  ensure  the  automation  is 
functioning  correctly,  and  be  able  to  intervene  when  necessary.  (Example  information  outputs  include 
anomaly  type,  severity,  impact,  priority,  etc). 

We  involved  SMEs  in  a  principled  and  systematic  design  process  that  leveraged  their  strengths  in 
domain  knowledge  and  avoided  discussions  of  intuitions  about  specific  HMI  formats  and  designs  for 
future  tasks  (e.g.,  Andre  &  Wickens,  1995;  Smallman  &  Cook,  2011).  We  developed  a  novel  procedure  in 
which  SMEs  made  design-impactful  decisions  based  on  their  expertise  and  anticipated  information 
needs  for  future  anomaly  detection  supervision.  Specifically,  SMEs  commented  on  their  anticipated 
needs  for  information  availability  and  information  detail  required  to  effectively  supervise  future 
anomaly  detection  automation.  This  process  helped  to  identify  the  information  access  costs  that  SMEs 
envision  accepting  for  accessing  information  in  a  future  supervisory  HMI  (Wickens  &  Hollands,  2000). 
SMEs  consistently  anticipated  needing  immediate  access  to  certain  aspects  of  anomaly  detection 
results,  such  as  general  categories  of  anomaly  types  and  severity,  and  were  willing  to  access  other 
information  on-demand  only  as  needed,  such  as  precise  values  for  ongoing  and  expected  problem 
duration.  We  have  successfully  employed  a  similar  process  with  other  SMEs  in  the  support  of  HMI 
designs  that  are  being  implemented  in  submarine  command  and  control  systems  and  industrial  process 
control  software.  The  results  from  these  interviews  directly  informed  the  design  of  low-fidelity  initial 
prototype  visualizations  reported  in  Smallman  and  Cook  (2013).  The  prototype  visualizations  support  a 
trend-based  approach  to  monitoring,  to  enable  users  to  monitor  and  supervise  proactively,  with  context 
incorporated  to  aid  in  understanding  and  interpretation  of  anomalies. 

Conclusions 

The  DoD  vision  for  the  future  of  autonomy  (DoD,  2011)  is  extremely  ambitious.  It  envisions  a  massive 
increase  in  the  number  of  autonomous  systems,  all  functioning  with  an  entirely  different  business 
process  than  today's  teams  of  humans  and  unmanned  vehicles.  The  role  of  the  human  will  change  from 
operators  of  single  vehicles  and  systems  to  supervisors  of  swarms  of  autonomous  and  highly  automated 
systems  performing  multiple  simultaneous  missions. 

The  DoD  vision  is  multi-faceted,  thus  requiring  a  multi-faceted  approach  to  achieve  it.  Currently,  most 
effort  is  directed  towards  developing  the  technology  and  the  supporting  infrastructure  for  the 
autonomous  capabilities.  Although  this  is  essential,  alone  it  is  not  sufficient  to  achieve  the  vision.  The 
notion  of  engineering  humans  out  of  the  system  is  a  science  fiction  (e.g.,  Skynet )  that  is  neither  viable 
nor  helpful.  Future  autonomous  systems  and  swarms,  no  matter  how  automated,  will  still  be  part  of  a 
complex  system  that  ultimately  includes  and  reports  to  human  decision  makers  and  arbiters.  Our  focus 
in  the  current  effort  has  been  on  the  work  paradigm  shift  towards  supervisory  control  and  supporting 
the  needs  and  increasing  work  demands  on  this  future  human  decision  maker. 

Although  the  sophistication  of  future  automation  will  undoubtedly  increase  in  20  years,  the  cognitive 
abilities  of  future  human  supervisors  will  not.  Effectively  supporting  the  future  autonomous  system 
supervisor  requires  careful  definition  of  their  future  tasking,  tools  and  HMIs  that  support  it,  and  viable 
supervisory  control  mechanisms,  all  presented  in  a  way  that  respects  users'  perceptual  and  information 
processing  characteristics.  Supporting  the  future  supervisor  also  requires  careful  consideration  of  the 
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display  metaphors  proposed  to  enable  users  to  do  their  tasks.  Current  displays  tend  to  promote  a 
reactive  monitoring  stance,  which  is  at  odds  with  the  needs  of  operators  to  monitor  proactively.  The 
importance  of  proactivity  will  grow  as  future  supervisors  monitor  automation;  they  will  need  to 
understand  what  parts  of  the  situation  are  beginning  to  trend  away  from  normal,  so  that  efforts  can  be 
focused  on  intervening  and  correcting  before  the  situation  deteriorates  and  cannot  be  remediated.  New 
display  metaphors  to  support  the  shift  towards  supervision  are  needed  (Smallman  &  Cook,  2013). 
Through  our  UCD  approach  paired  with  expertise  in  perceptual  and  cognitive  science  and  the 
supervisory  control  of  automation,  we  have  begun  to  make  inroads  into  this  complex  problem. 

The  ambition  and  complexity  of  the  DoD  vision  has  required  us  to  tailor  classic  UCD  processes  to  the 
problem.  Classically,  UCD  entails  interviewing  domain  experts  and  building  task  models  for  the  design  of 
capabilities  firmly  grounded  in  today's  realities  (e.g.,  Norman,  1986).  For  the  futuristic  DoD  vision, 
however,  current  users  cannot  definitively  envision  the  future  supervisor's  job.  They  do  not  know  what 
future  mission  types  and  requirements  will  be.  They  cannot  foresee  the  vehicles  and  systems  that  will  be 
employed,  and  they  have  little  experience  employing,  trusting,  and  valuing  automation  (Lee  &  See, 
2004).  However,  across  the  different  roles  that  current  users  take,  the  different  platforms  and  vehicles 
they  operate,  the  different  missions  they  conduct,  and  the  experiences  with  different  HMIs  and 
automation  that  they  accumulate,  current  users  can  usefully  ground  an  understanding  of  future  tasking. 

We  therefore  approached  and  solicited  input  from  a  large  sample  of  27  SMEs  selected  to  cover  the 
requisite  experiences  in  roles,  mission  types,  vehicle  types,  and  automation.  Our  constraints  were 
significant.  Individual  SMEs  had  limited  time  to  devote  to  a  limited  set  of  issues.  We  therefore  employed 
a  carefully  scoped,  staged,  sequential,  interactive  UCD  approach  where  the  products  resulting  from  one 
site  visit  with  one  SME  group  were  progressively  built  upon  in  subsequent  site  visits  with  different  SME 
groups.  We  scoped  our  analysis  to  the  monitoring  aspect  of  supervisory  control,  which  is  widely 
considered  to  be  the  most  challenging  (Sheridan,  2006).  We  staged  the  UCD  sessions  across  four  military 
and  commercial  industry  sites  in  the  US  specializing  in  training,  development,  testing,  and  operation  of 
unmanned  vehicles. 

The  design  artifacts  resulting  from  these  interviews  include  a  descriptive  model  of  today's  monitoring 
and  intervention  tasks  for  unmanned  vehicles,  and  a  prescriptive  model  for  tomorrow's  vision  of  how 
those  same  tasks  should  be  allocated  to  humans  and  automation  working  cooperatively,  as  well  as  the 
information  exchanges  needed  for  future  supervisors  to  manage  future  automation.  We  used  an  existing 
framework  for  automation  design  (Parasuraman  et  al.,  2000)  and  applied  it  in  a  novel  way  to  task 
analysis  with  domain  experts,  providing  an  objective  basis  for  SMEs  to  offer  their  expectations  about  the 
future  role  of  automation.  We  balanced  the  roles  of  the  different  stakeholders  in  the  UCD  process, 
harnessing  the  strengths  of  the  different  stakeholders  in  a  synergistic  way,  with  the  SMEs  providing 
domain,  task,  and  technology  expertise,  and  the  human  factors  scientists  /  designers  applying  expertise 
in  perceptual  and  cognitive  science  and  the  supervisory  control  of  automation. 

By  tackling  these  issues  now,  we  can  stay  ahead  of  the  autonomy  revolution  with  solutions  that  guide 
the  technology  to  support  the  users,  rather  than  making  the  users  "slaves  to  the  technology." 
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Problem 


DoD  future  vision:  role  shift  for 
human  operator  of  autonomous 
systems  (DoD,  2009) 

How  to  achieve  vision? 

Challenges  with  autonomy 

Problems  with  today's  single 
vehicle  control  systems,  support 
tools,  and  human-machine 
interfaces  (HMIs) 

Need  new  decision  support 

Need  principled  basis  for  designing 
decision  support  tools,  HMIs,  and 
automation  for  future  user 


Supervise  and  monitor  autonomous 
platforms  and  agents  through  HMIs 

Make  decisions  about  when  and 

how  to  intervene 
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Assumptions  for  future 


•  Dynamic,  uncertain,  unpredictable, 
degraded  operating  environments 

•  Human  role  will  evolve  with  sophistication 
and  capabilities  of  automation 

-  Larger  span  of  control  (eventually  multiple 
vehicles,  systems,  missions) 

-  Automation  limitations  (e.g.,  inherently 

brittle  (Layton,  Smith,  &  McCoy,  1994)) 

-  User  will  supervise  automation  and 
situations,  and  intervene  to  correct  when 
necessary 

•  Human  always  needed  as  decision  maker  and  ultimate  arbiter 

•  Shift  to  supervisory  decision  making  requires  accompanying 
shift  in  decision  support 


mission-level 
goals,  tasks, 
status 


©  Pacific  Science  &  Engineering  2013 


3 


Challenges  for  achieving  DoD 
autonomous  systems  vision 


•  Technology  and  human  issues 
to  overcome  to  support  role 
shift  of  the  human  operator 


2011 

2012 

2013 

2014  2015 

2016 

2017 

2018 

2019 

2020 

2025+ 

Design  for 
Certification 


DoD  Roadmap 

technology  Reason, CjjjjgM.  Sci.nc.  “ 

(investments  and  timeline) 


Capability 


Robust  decision 
making 


Integration  of 
disparate  info 


Autonomous  PED 
Evaluation 
Environmental 
Understanding  and 
Adaptation 


Autonomous 

Collaboration 


Primary  focus  on  technology  advancement;  unresolved 
user  issues 


Substantial  manning  requirements 

^  human  causal  factors  in  UAS  mishaps 

(Tvaryanas,  Thompson,  &  Constable,  2006) 

Under-utilized  autonomy  (OSD,  2012) 

Inadequate  support  tools  and  human 
machine  interfaces  (HMIs) 

Work-arounds  to  compensate 


"It  feels  like  90%  of  our  training 
involves  developing  and 
teaching  work-arounds  to  get 

the  system  to  do  what  we  need" 

—Vehicle  Pilot  Trainer,  discussing 
current  systems/HMIs 
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Support  tools  and  HMIs  lagging 
behind  technology 


Inconsistencies  in  coding  and 
meaning  across  HMIs  and  platforms 

•  Cross-platform  transfer  minimized  due  to  different 
HMIs  and  systems  for  different  platforms 

•  Inconsistent  use  of  visual  features  (e.g.,  color) 
within  and  across  systems 


Insufficient  decision  support  (for 
assess  and  decide) 

•  User  burdened  to  find,  mentally  integrate,  and 
transform  data  into  decision  -evel  information 

•  Uninformative  and  context-insensitive  alerts 


mmm 


Inadequate  attention  management  support 
(for  monitor  and  detect ) 

•  Poor  support  for  monitoring  and  comprehension  of  changes 
overtime,  and  proactive  monitoring 

•  Forces  serial,  continuous,  reactive  monitoring  stance 

•  Users  burdened  to  determine  and  focus  on  what  is  task¬ 
relevant,  and  filter  out  the  task-irrelevant 


Lack  of  automation  support  and 
transparency 

•  Confusing  and  poorly  conveyed  mode 
hierarchy  and  authority 

•  Limited  insight  into  automation 


Function  and  task  complexity 

Simple  functions  and  tasks  require 

memorization  and  training  of  complex, 

multi-step  procedures 

Training  focused  on  compensating  for  HMI 

shortfalls  detracts  from  teaching  core 

objectives 


Representative  Human 
Machine  Interfaces  (HMIs) 


•  Problems  seen  today  are  similar  to  problems  reported  in  2004,  2006 

(Eaton,  Kalita,  &  Nagy,  2006;  Tvaryanas,  Thompson,  &  Constable,  2006;  Williams,  2004) 

c «  Need  new  approach! _ 
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Design  and  domain  challenges 


•  Situation  and  user  population  do  not  yet  exist 

-  Must  evolve  traditional  methods  of  analyzing  existing  work,  systems,  and 
users 

•  Human-automation  interaction 

-  "Double-edged  sword"  nature  of  automation  (Bainbridge,  1983) 

•  System  development  constraints 

-  Technology-centric  philosophy 

-  Change  averse,  slow  progress  and  improvements  (Tvaryanas,  2012;  Williams,  2004) 

•  Increase  in  future  span  of  control 

-  More  information  to  monitor,  but  same  user  cognitive  abilities  and  user 
"bandwidth" 

-  Minimal  progress  through  prior  attempts  (MAC) 
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Design  and  domain  challenges 


•  Situation  and  user  population  do  not  yet  exist 

-  Define  core  tasks  as  basis  for  defining  future  user  task  needs 

•  Human-automation  interaction 

-  Human-centered  philosophy,  principled  method  to  allocate  tasks  to  humans 
and  autonomy 

•  System  development  constraints 

-  Task-centered  to  direct  focus  on  users' needs 

-  Objective  basis  for  selecting  HMIs  and  tools 

•  Increase  in  future  span  of  control 

-  Information  presentation  and  interactions  aligned  with  users' 
cognitive  abilities 
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Tailored  User-Centered  Design 

(UCD)  process 


Ado/v  cognitive  science  to  support  user  abilities 

Cognitive  Human- 


Cognitive  task  automation 

challenges  analyses  allocation 


"Monitoring" 
work  domains 


Cognitive 

science 


Performance 

tradeoffs 


Define 

tasks, 

roles 


> 


Allocate 

tasks 

across 

users, 

system 


> 


Specify 

info 

exchanges, 

workflow 


> 


Q)  £?  r_ 

^k  ^tk  ^k 


Operational  Task,  Automation 

docs  domain  allocation 


Info  User  task  &  Feedback  on 

exchanges  display  constraints  concepts,  usage 


IV-V-UL/U\-I\  IV^V^UUUV^IX 


Apply  domain  expertise  to  support  future  task,  needs 


27  military  and  industry  unmanned  systems  subject  matter  experts  (SMEs) 
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Staged  SME  interview  process 
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Staged  task  analysis 
approach 


Decide 
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Dcectteorr  to  bu*d  anewf^ht  path 
Dr«ct  tearr  to  wart wv«f  daftftntty \toca»»l 


(D 


Specify  allocation  of  tasks 
to  human  and  automation 
for  current  ("descriptive") 
and  future  ("prescriptive") 
practice 


<D 


Specify  information 
exchange  between 
humans  and  automation 
for  subset  of  "detect" 
tasks 
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SME  participant  characteristics 


27  military  and  civilian  unmanned  system  domain  experts  experienced  in: 

•  Vehicle  Control,  Sensor  Control,  Mission  Command 

•  Range  of  unmanned  vehicle  platforms  (DoD  UAS  Group  1-5) 

•  Range  of  missions,  from  operational  tests  through  theater  operations 


Stage  1 


Stage  l]< 


Stage  3 


Unmanned  Vehicle  Role 

DOD  UAS  Group 

Date 

Site 

Rate  &  Rank  or  Civilian 

] 

} 

2 

4 

5 

Vehicle 

Sensor 

MC 

Consult 

Exp 

Yrs 

Exp 

Yrs 

Exp 

Yrs 

Exp 

Yrs 

Exp 

Yrs 

April 

Navy  exercise 

0-5  [CDR1  Ret 

X 

May 

Military  test  venue 

Capt/06 

X 

X 

X 

Expt 

14 

Expt 

14 

Expt 

10 

May 

Military  test  venue 

Civilian 

X 

X 

Expt 

7 

May 

Military  test  venue 

Civilian 

X 

X 

X 

Expt 

2 

Expt 

5 

May 

Military  test  venue 

Civilian 

X 

X 

X 

7 

May 

Military  test  venue 

Civilian 

X 

X 

Expt 

5 

June 

Industry  UAS 

Stan  /  Eval  Instructional  Auditor 

X 

X 

X 

Expt 

4 

June 

Industry  UAS 

Operations  Action  Center 

X 

X 

Int 

3 

June 

Industry  UAS 

02  [former  service)  /  FSR 

X 

X 

Int 

2 

June 

Industry  UAS 

E5  [former]  /  Field  Service  rep 

X 

X 

Expt 

3.5 

June 

Industry  UAS 

E6  /  Fire  Servie  Trainer 

X 

X 

X 

Int 

4 

June 

Industry  UAS 

E7  [Ret]  /  Pilot  Instructor 

X 

X 

X 

Expt 

3.5 

Expt 

4 

June 

Industry  UAS 

UAS  Instructor  /  Operator 

X 

X 

Expt 

2.25 

June 

Industry  UAS 

Airline  Pilot  /  Training  Program  Mgr 

X 

X 

Expt 

5 

June 

Industry  UAS 

0-4  [Ret]  /  Director  of  Mission  Support 

X 

X 

X 

Int 

1 

Expt 

2 

June 

Industry  UAS 

Operator  Training  Mgr 

X 

X 

X 

Expt 

7 

June 

Industry  UAS 

0-4/ Advanced  Operations  Training 

X 

X 

X 

Expt 

3 

Int 

2 

June 

Industry  UAS 

Pilot  Instructor 

X 

Expt 

3 

June 

Industry  UAS 

UAS  Pilot  Instructor 

X 

Expt 

1.25 

July 

AFtraining 

0-4/ Mai 

X 

Expt 

3.5 

July 

AF  training 

0-4/ Mai 

X 

Expt 

5 

July 

AF  training 

Maj 

X 

X 

Expt 

2 

Expt 

2.75 

July 

AF  training 

Maj 

X 

Expt 

4.92 

July 

AFtraining 

TSfit 

X 

Int 

1.33 

Expt 

3.17 

July 

AFtraining 

TSfit 

X 

Expt 

11 

July 

AFtraining 

TSfit 

X 

Expt 

2 

Expt 

2 

July 

AFtraining 

X 

Expt 

3 

Expt 

5 

Total 

27 

22 

19 

11 

1 

Avg 

14.0 

3.7 

5.7 

2.7 

4.3 
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Interactive  interviews 


•  Draft  materials  for 
SMEs  to  respond  to 

•  SMEs  active 
participants  in 
interviews 


Contact,  agenda, 

recruitment, 

schedule 


Create  materials,  f|B 
procedure;  IRB 


Overview  of 
ONR  project 
and  interviews 


Simulator  and 


system/HMI  Sjj 

review  v 


Outbrief  and 
SME  follow-up 


Analysis  and 
design... 
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Stage  1:  Defined  core  tasks  in 
role-task  matrix 


•  Drafted  role-task  matrix  for  monitoring 
and  problem  intervention  tasks 

•  Leveraged  from  prior  task  analyses, 
operational  docs  and  CONOPS  (e.g.,  Cook  & 

Smallman,  2010;  Fleet  Forces  Command,  2008;  Gugerty,  2004;  Nehme, 
Crandall,  &  Cummings,  2007;  OSD,  2012;  Sibley  8i  Coyne,  2012) 

•  Tasks 

-  Monitor  (vehicles,  environment,  sensors, 
team,  mission) 

-  Detect  anomalies  or  problems 

-  Assess  ability  and  need  to  fix  problem 

-  Decide  on  course  of  action 

•  Roles 

-  Configuration  of  users  and  automation 

•  Align  decision  support  efforts  to  task 
needs 

•  Reviewed  and  refined  with  SME  feedback 
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Stage  1:  Defined  core  tasks  in 
role-task  matrix 


V 


_ 


i 


Abstracted  tasks  and  current  allocation  to  humans  and  automation  for  current  UAV  operations 


Detect 


Assess 


Decide 


Environment  (air,  ground) 


Sensor  (camera  or  payload) 


Q. 

O 


E 

E 

o 

u 


n  (vehicle  and  sensor 
operators) 


Mission  (air  space  and 
customer  requirements) 


Ongoing  or  anticipated  anomalies  or  problems  in  vehicle  health  and 
status  (out  of  range  cylinder  head  temp,  engine  RPMs,  instrument 
malfunctions,  insufficient  remaining  fuel) 

Ongoing  or  anticipated  anomalies  in  vehicle  movements  ( rate  of 
climb,  flight  path  deviations) 

Ongoing  or  anticipated  problems  with  connectivity  to  vehicle 


Obstacles  or  events  in  the  vehicle's  path  that  might  impact  vehicle 
safety,  health,  or  status  (winds  aloft,  anti-aircraft  artillery) 

Obstacles  or  events  in  the  vehicle's  path  that  might  impact  safety  of 
other  aircraft  (manned  aircraft) 

Obstacles  or  events  in  the  vehicle's  path  that  might  adversely  affect 
vehicle  movements  (winds,  weather) 

Obstacles  in  the  path  of  the  camera  that  might  degrade  quality  of 
collection  or  targeting  (fog) 

Events  or  obstacles  impacting  or  likely  to  impact  mission  goals  (poor 
weather  delaying  target  arrival  time) 


Ongoing  or  anticipated  anomalies  in  sensor  functioning 
(malfunctioning  zoom,  unresponsive  on/off) 

Ongoing  or  anticipated  problems  with  sensor  connectivity 
Ongoing  or  anticipated  problems  with  collection  quality  (unable  to  ID 
or  distinguish  targets  due  to  degraded  video) 

Ongoing  or  anticipated  problems  with  collection  accuracy  (cannot 
find  or  track  white  truck  target) 

Ongoing  or  anticipated  problems  with  interpreting  collection 
(meaning  of  target  behavior,  changes  over  time) 


Events  impacting  or  likely  to  impact  team  performance  (poor  sensor 
performance  of  one  operator;  additional,  unexpected  tasking) 


Events  impacting  or  likely  to  impact  mission  effectiveness  (delayed 
mission  schedule) 

Events  impacting  or  likely  to  impact  airspace  during  mission  (airspace 
closures;  other  air  vehicles) 

Events  impacting  or  likely  to  impact  customer  satisfaction  (loss  of 
target) 

Events  impacting  or  likely  to  impact  the  bigger  picture  (interaction  of 
other  missions  with  current  mission) 


Need  to  fix  the  error  or  problem  (should  I  fix?) 
o  Severity  of  the  anomalies,  problems,  or  deviations 
o  Likelihood  of  anomalies,  problems,  or  deviations 

o  Degree  of  impact  from  anomalies,  problems,  or  deviations  (should  they  occur) 
o  Risk  to  vehicle,  sensors,  collateral  entities,  and  mission  if  current  flight  plan  is  continued 
o  Risk  to  vehicle,  sensors,  collateral  entities,  and  mission  goals  if  current  flight  plan  is  abandoned  or  changed 
Ability  to  fix  the  error  or  problem  (can  I  fix?) 
o  Capabilities  and  health/status  of  the  vehicle 
o  Allowable  path  tolerance  (min  separation ) 
o  Time  remaining  to  complete  mission 
o  Potential  to  correct  error  with  minimal  risk  and  cost 


Need  to  avoid  obstacle  or  work  around  event 
o  Likelihood  of  impact  from  obstacles  or  events 
o  Degree  of  impact  from  obstacles  or  events 

o  Risk  to  vehicle,  sensors,  collateral  entities,  and  mission  if  current  flight  and  sensor  plan  is  continued 
o  Risk  to  vehicle,  sensors,  collateral  entities,  and  mission  goals  if  current  flight  and  sensor  plan  is  abandoned  or  changed 
(changing  flight  path  leading  to  loss  of  connectivity  or  sight  of  a  track,  compromising  stealth) 

Ability  to  avoid  obstacle  or  work  around  event 

o  Given  the  environmental  conditions  (terrain  features,  wind  speed,  airspace  changes,  landmarks,  waypoints ), 

•  Capabilities  and  health/status  of  the  vehicle 

•  Alternative  waypoints  or  paths  available 

•  Time  remaining  to  complete  mission 

•  Potential  to  correct  error  with  minimal  risk  and  cost 


Need  to  fix  the  error  or  problem 

o  Quality  of  collection  (how  bad  is  the  imagery ?) 

o  Accuracy  of  collection  (degree  of  match  between  expected  and  actual?) 

o  Confidence  in  interpretation  of  the  collection  (/  see  a  pattern  emerging  but  I  do  not  know  what  it  means) 

o  Risk  to  vehicle,  sensors,  collateral  entities,  and  mission  if  current  sensor  plan  is  continued 

o  Risk  to  vehicle,  sensors,  collateral  entities,  and  mission  goals  if  current  sensor  plan  is  abandoned  or  changed 

Ability  to  fix  the  error  or  problem 

o  Capabilities  and  health/status  of  the  payload  or  sensor 

o  Alternative  targets  or  collection  opportunities  available 

o  Time  remaining  to  complete  mission 

o  Potential  to  correct  error  with  minimal  risk 

o  Additional  analysis  resources  to  support  processing  and  exploitation 


Need  to  replace  the  operator 
o  Performance  of  the  team  overall 

o  Risk  to  vehicle,  sensors,  collateral  entities,  and  mission  if  current  teant  configuration  is  continued 

o  Risk  to  vehicle,  sensors,  collateral  entities,  and  mission  goals  if  current  team  configuration  is  abandoned  or  changed 

o  Extent  to  which  the  human  is  causing  the  problem 

o  Potential  to  correct  human  error  with  minimal  risk  and  cost 

Ability  to  replace  the  operator 

o  Capabilities  and  status  of  alternative  operators 

o  Potential  to  replace  operator  with  minimal  risk  and  cost 


Need  to  modify  the  mission  under  the  circumstances 

o  Risk/reward  to  vehicle,  sensors,  collateral  entities,  and  mission  if  current  flight/sensor  plan  is  continued 

•  Completion  status  of  the  current  mission 

•  Importance  of  mission  tasks 

•  Extent  to  which  customer  can  be  or  has  been  satisfied 

o  Risk/reward  to  vehicle,  sensors,  collateral  entities,  and  mission  goals  if  current  flight/sensor  plan  is  abandoned  or  changed 

•  Completion  status  of  the  current  mission 

•  Importance  of  mission  tasks  (mission  priorities  and  schedule,  key  transitions  for  events,  major  and  minor  changes  in 
targets  or  activity  of  observed  entities,  target  tracking  performance) 

•  Extent  to  which  customer  can  be  or  has  been  satisfied 
■  Probability  of  recovery,  vehicle  sacrifice  method 

Ability  to  modify  the  mission  under  the  circumstances 
o  Capabilities  and  health/status  of  the  vehicle 
o  Alternative  waypoints  or  paths  available 
o  Time  remaining  to  complete  mission 
o  Potential  to  correct  error  with  minimal  risk  and  cost 
o  Tactical  context  (go/no-go  criteria) 


Continue  with  current  flight  plan 
Return  vehicle  to  base  to  inspect,  fix,  or  replace  vehicle 
Maneuver  differently  to  correct  movement 
Attempt  to  regain  connectivity 


Continue  with  current  flight  and  sensor  plan 
Return  vehicle  to  base  to  inspect,  fix,  or  replace  vehicle 
or  sensor 

Maneuver  differently  (locally)  to  correct  movement  or 
avoid  obstacle 

Build  a  new  flight  path  (globally)  to  correct  movement  or 
avoid  obstacle 

Use  alternate  sensor  to  deal  with  environmental 
obstacles 


Continue  with  current  sensor  plan 

Return  vehicle  to  base  to  inspect,  fix,  or  replace  sensor 

Maneuver  differently  (locally)  to  improve  collection 

quality 

Build  a  new  flight  path  (globally)  to  improve  collection 
quality 

Use  alternate  sensor  to  compensate  for  sensor 
malfunction,  poor  collection  quality 
Collect  on  a  new  or  related  target  in  the  vicinity  (for  the 
same  mission) 


Replace  operator(s) 

Assist  operator(s) 

Continue  with  current  operator(s) 


Direct  team  to  continue  with  current  flight  and  sensor 
plan 

o  Decide  that  current  collection  is  sufficient 
o  Decide  that  current  vehicle  operations  are  sufficient 
Direct  team  to  return  vehicle  to  base  to  inspect,  fix,  or 
replace 

Direct  team  to  build  a  new  flight  path  (globally) 

Direct  team  to  maneuver  differently  (locally) 

Direct  team  to  change  sensor  collection  plan 
Direct  team  to  collect  on  a  new  or  related  target 


TT 
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Stage  2:  Specified  task  allocation 


•  SMEs  applied  expertise 
about  tasks,  specifying 
how  users  and  automation 
do/can  work  jointly  to 
accomplish  tasks 

-  Novel  procedure  by 
adapting  method  used  for 
system  designers  to  allocate 
tasks  (Parasuraman,  Sheridan, 
&  Wickens,  2000) 

-  Objective  basis 

-  Rough  guidelines  to  aid 
ratings 

-  Present  ( descriptive ) 

-  Future  (, prescriptive ) 
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Defined 
tasks  (Stage 
jl  role-task 

matrix) 

— 


Humans  excel  at: 

Computers  excel  at: 

Perceiving  patterns,  problem  solving 

Responding  quickly  to  control  tasks 

Improvising  and  using  flexible  procedures 

Repetitive  and  routine  tasks 

Recalling  relevant  facts  at  the  appropriate  time 

Handling  many  tasks  simultaneously 

Human 

l 

Fully  Human: 

»  Automation  offers  no 
assistance;  human 
makes  all  decisions  and 
takes  all  actions 


Rating  scale 

2  3  © 


Human  Delegated: 

•  Automation  suggests 
multiple  alternatives  or 
categorized  data  for 
human  to  choose  from 


Human  Supervised: 

•  Automation  suggests 
one  alternative  for 
human  to  accept  or 
veto  ("management  by 
consent") 


Nearly  Autonomous: 

•  Automation  executes 
one  alternative,  giving 
human  limited  time  to 
veto  ("management  by 
exception") 


Automation 

© 

Fully  Autonomous: 

•  Automation  decides 
everything  and  acts 
independently, 
ignoring  the  human 


Clerk  manually  types  in 
all  items  at  point  of 
purchase;  no  assistance 
from  automation 


Clerk  swipes  all  items 
over  the  scanner  and 
automation  provides: 
S  "First  pass"  alerts  to 
issues  or  anomalies 
Multiple  options  for 
human  to  choose 
from 


Clerk  swipes  all  items 
over  the  scanner  and 
automation  provides: 
S  Awareness  of  the 
issues  or  anomalies 
S  Single  option  for 
human  to  acceptor 
veto 


Clerk  swipes  all  items 
over  the  scanner  and 
automation  provides: 
S  Understanding  of  the 
issues  or  anomalies 
'S  Single  solution 
without  requiring 
human  approval 


Customer  pushes  cart 
through  scanner  and 
automation  reads  all 
barcodes  or  ID  tags  at 
once  and  tallies  the 
total 


\ 


Lower  speed,  lower  volume  (high  workload  for  human) 

Can  fix  problems  by  manually  entering  or  confirming  them 

More  direct  and  timely  customer  service 

Higher  speed,  higher  volume  (narrows  down  options) 

May  exclude  "good"  items  or  may  miss  "bad"  items 

Customer  service  could  be  less  timely  or  nonexistent 

Requires  long-term  knowledge  or  interpretation 

Procedure  that  is  context-dependent 

Allows  focus  on  single  issue  at  a  time 

Consequences  of  failing  are  serious  (death,  injury,  etc.) 

Can  be  performed  without  applying  long-term  knowledge 
Procedure  with  defined  rules  that  apply  across  varied  contexts 

1  Requires  large  amounts  of  data  to  be  processed  simultaneously 

Consequences  of  failing  are  minor 

TT 


ocated 
tasks  (Stage 
2  role-task 
matrix) 
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Stage  2:  Allocation  process 


Example  task:  "Detect  ongoing  or  anticipated  anomalies  or  problems  with  vehicles'  health  and  status" 


•  User  monitors  vehicle  health  and  status  and  is 
responsible  for  detecting  all  deviations  or  problems 

( 1  -Fully  human) 

For  2-5,  "detection"  automation  helps  monitor  the 
health  and  status  of  vehicles  and: 

•  notifies  user  of  a// deviations;  user  must  review  all 
notifications  and  decide  which  ones  are  critical  and 
which  to  dismiss  ( 2-Human  delegated) 

•  notifies  user  of  subset  of  most  critical  deviations,  for 
the  user  to  review  and  approve  or  dismiss  (similar  to 
"management  by  consent")  ( 3-Human  supervised) 

•  decides  on  the  subset  of  critical  deviations;  the  user 
can  dismiss  notifications  within  a  given  time  period 
(similar  to  "management  by  exception")  ( 4-Nearly 
autonomous) 

•  decides  on  the  subset  of  critical  deviations;  the  user 
has  no  ability  to  review  or  dismiss  notifications  (5- 

Fully  autonomous) 
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Stage  2:  Specified  task  allocation 


Vehicle  (health, 

kinematics) 


QJ 

a 

o 

QJ 


QJ 

> 


QJ 

a. 

O 


</>  g 

o  c 

.2 


Tasks 


Monitor 


ng  or  anticipated  anomalies  or  problems  in  vehicle  health  and 
(out  of  range  cylinder  head  temp,  engine  RPMs,  in: 
malfunctions.  Insufficient  remaining  fuel ) 


Ongoing  or  anticipated  problems  with  connectivity  to  vehicle 


Environment  (air, 

ground) 


Sensor  (camera  oi 

payload) 


Detect 


Current 


Future 


y,  health,  or  st 

Obstacles  or  events  in  the  vehicle's  path  that  mfeht  impact  safety  of 

went*  in  the  vehicle's  path  that  might  adversely  affect 
movements  (winds,  weather ) 

les  In  the  path  of  the  camera  that  might  degrade  quality  of 
or  targeting  | fog) 

obstacles  Impacting  or  llkefy  to  Impact  minion  goals  (poor 


or  functioning  ( malfunctioning 


Ongoing  or  anticipated  problems  with  se 

or  anticipated  problems  with  colection  quaSty  I  unable  to  ID  or 
ts  due  to  degraded  video  I 

or  anticipated  problems  with  colection  accuracy  (connof  find  or 
track  white  truck  target ) 

anticipated  problems  with  interpreting  collection  (meaning  of 


Assess 


Current 


Future 


:ed  to  fix  the  error  or  problem  (should  I  fi*?> 
Severity  of  the  anomalies,  problems,  or  deviations 


Degree  of  impact  from  anomalies,  problems,  or  deviations  (should  they  occur) 

Risk  to  vehicle,  sensors,  collateral  entities,  and  mission  If  current  flight  plan  is  continued 
Risk  to  vehicle,  sensors,  collateral  entitles,  and  mission  goals  If  current  flight  plan  is  abandoned  or 
anged 

lility  to  fix  the  error  or  problem  (can  I  fix?) 

Capabilities  and  health/status  of  the  vehide 
Allowable  path  tolerance  (min  separation) 

Time  remaining  to  complete  mission 

Potential  to  correct  error  with  minimal  risk  and  cost 


Continue  with  current  flight  plan 

vehicle  to  base  to  inspect,  fix.  or  replace  vehicle 
differently  to  correct  movement 
o  regain  connectivity 

Return  to  base  In  event  of  lost  communications 


sk  to  vehide,  sensors,  collateral  entities,  and  mission  If  current  flight  and  sensor  plan  is  continue 
sk  to  vehide.  sensors,  collateral  entities,  and  mission  goals  if  current  flight  and  sensor  plan  is 
loned  or  changed  ( changing  flight  path  leading  to  loss  of  connectivity  or  sight  of  o  track. 


Ml) 


Ability  to  avoid  obstacle  or  work  around  event 

Given  the  environmental  conditions  (terrain  features,  wind  speed,  airspace  changes,  landmarks, 
waypoints). 

Capabilities  and  health/status  of  the  vehicle 
Alternative  waypoints  or  paths  available 


ir  with  minimal  risk  and  cost 


•  Time 
«  Potential  to  correct  er 


Need  to  fix  the  error  or  problem 

Quality  of  collection  (how  bad  is  the  Imagery?) 

Accuracy  of  coflectlon  (degree  of  match  between  expected  and  actual?) 

Confidence  in  interpretation  of  the  collection  (I  see  a  pattern  emerging  but  I  do  not  know  what  it  meai 

Risk  to  vehicle,  sensors,  collateral  entities,  and  mission  if  current  sensor  plan  is  continued 

Risk  to  vehide,  sensors,  collateral  entitles,  and  mission  goals  if  current  sensor  plan  Is  abandoned  or 


Ability  to  fix  the  error  or  problem 

Capabilities  and  health/status  of  the  payload  or  sensor 
Alternative  targets  or  collection  opportunities  available 
Time  remaining  to  complete  mission 

to  correct  error  with  minimal  risk 


Emergent  Patterns 


Decide 


Current 


Future 


Continue  with  current  flight  and  sensor  plan 

i  vehicle  to  base  to  Inspect  fix.  or  replace  vehicle  or 


flight  path  (globally)  to  correct  movement  or 
to  deal  with  environmental  obstacles 


Continue  with  current  sensor  plan 

Return  vehicle  to  base  to  Inspect  fix.  or  replace  sensor 

Maneuver  differently  (locally)  to  improve  collection  quality 

>  new  flight  path  (globally)  to  improve  collection 

r 

Use  alternate  sensor  to  compensate  for  sensor 
malfunction,  poor  coflectlon  quality 

lied  on  a  new  or  related  target  in  the  vidnity  (for  the 
ne  mission) 

in  mode  set  by  payload  operator  or  scan  continuously 


Humans  heavily  involved  in  most  current  tasks  (autonomy  under-utilized) 

-  Echoes  recent  Role  of  Autonomy  in  DoD  Systems  OSD  report 

SMEs  envision  future  automation  helping  with  "detect"  and  "assess"  for  vehicles, 
sensors,  environment 

Relatively  more  human  involvement  reserved  for  "decide"  and  mission  commander 


tasks 


Human 

Supervised 


Nearly 
Autonomous 


Fully 
Autonomous 
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Roadmap  for  future  automation  and 

support  tools 


o 

4-< 

ro 

k_ 

<U 

a 

o 

<U 


O) 

> 


Tasks 


Monitor 


Vehicle  (health, 

kinematics) 


ng  or  anticipated  anomalies  or  problems  in  vehicle  health  and 
(oof  of  range  cylinder  head  temp,  engine  RPMs,  in 
malfunctions.  Insufficient  remaining  fuel ) 

Ongoing  or  anticipated  anomalies  In  vehicle  movements  ( 


Ongoing  or  anticipated  problems  with  connectivity  to  vehicle 


Environment  (air, 
ground) 


Detect 


Current 


Future 


Need  to  fix  the  error  or  problem  (should  l  fix?) 

Severity  of  the  anomalies,  problems,  or  deviations 


Obstacles  or  events  in  the  vehicle's  path  that  mfcht  impact  safety  of 

cles  or  events  in  the  vehicle's  path  that  might  adversely  affect 
;  movements  (winds,  weather) 

des  In  the  path  of  the  camera  that  might  degrade  quality  of 
Son  or  targeting  (fog ) 

>  or  obstacles  Impacting  or  likely  to  Impact  mission  goals  (poor 


Assess 


Current 


Future 


Degree  of  impact  from  anomalies,  problems,  or  deviations  (should  they  occur) 

Risk  to  vehicle,  sensors,  collateral  entities,  and  mission  If  current  flight  plan  is  continued 
Risk  to  vehicle,  sensors,  collateral  entitles,  and  mission  goals  If  current  flight  plan  is  abandoned  or 
anged 

Ability  to  fix  the  error  or  problem  (can  I  fix?) 

Capabilities  and  health/status  of  the  vehicle 
Allowable  path  tolerance  (min  separation) 

Time  remaining  to  complete  mission 

Potential  to  correct  error  with  minimal  risk  and  cost 


Continue  with  current  flight  plan 
Return  vehicle  to  base  to  inspect,  fix. 

over  differently  to  correct 
Attempt  to  regain  connectivity 

Return  to  base  In  event  of  lost  communications 


■gree  of  Impact  from 

sk  to  vehicle,  sensors,  collateral  entities,  and  mission  If  current  flight  and  sensor  plan  is  continue 
sk  to  vehicle,  sensors,  collateral  entities,  and  mission  goals  if  current  flight  and  sensor  plan  is 
lotted  or  changed  (changing  flight  path  leading  to  lass  of  connectivity  or  sight  of  a  track. 


Ability  to  avoid  obstacle  or  work  around  event 

Given  the  environmental  conditions  (terrain  features,  wind  speed,  airspace  changes,  landmarks, 
waypoints). 


Decide 


Current 


Future 


Continue  with  current  flight  and  sensor  plan 

Return  vehicle  to  base  to  Inspect,  fix.  or  replace  vehicle  or 


flight  path  (globally)  to  correct  movement  or 
to  deal  with  environmental  obstacles 


Use  of  matrix 


•  Baseline  vs.  future 

•  Initial  step  in  design  of  joint  human-autonomous  system 
decision  support 

-  Automation 

-  HMIs  and  support  tools 
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Stage  2:  Specified  task  allocation 
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information  exchanges 


Today's  support 
tools  and  HMIs 
induce  reactivity, 
as  users  monitor 
real-time  values, 
and  respond  to 
alerts. 


•  Stay  abreast  of 
situation 

•  Address  problems 
that  arise 


No  determination 
of  how  to 

characterize  process 

No  determination  of 
what  to  track 
Focus  on  parameters  _ 
vs.  patterns 

Ignorance  of  context 


Reactive 


No  projection 
future  or  focus 


Today's 
monitoring 

No  consideration  I 


>  consideration  * 

pattemycross  — *■  ^ 

(reactive) 

issing  o^f  r  and  to  current  actual} _ ]  M 


Missing 
temporal  pattern 


1 


Assess 

significance  of 
parameter 
deviations 

IrtWaisessmefit 
of  reserving  or 
ntensifying 

Triage 

deviations 

Prioritized  list 
of  deviations 

Haphazard,  miss- 
prone  decision 
making  under 
time  pressure, 
divorced  from 
current  context 


•  Stay  abreast  of 

•  Address  changes  Proactive 

before  they 
become  probf 


ie  problems 


Key  parameters 
define  attentional 
focus.  Needs  to  be 
accurate. 


Determine  how 
to  characterize 


state  parameter?  & 
thei-pats-nsor 
nermaity  l’//\3tto 
do)  &  tolerance 


Need/  I 


Tomorrow's 


supervision 

Assessment  of 
past  patterns  A 

M  patterns  —  ^ 

(proactive) 

^  I  pattern  of  actual  expected  * 


Smallman  &  Cook,  2013  (HCII) 


Future  tools  and  HMIs 
should  support  proactivity 
and  mission-level 
supervision. 


Plant  State 

Catastrophic 

Loss 

Wrong  action  makes 

the  situation  worse  /Noactjon 

Lost  Production 
or  Equipment 

I  /  ,  Late  action  results  in 

/  /  y/  losses 

Normal 

Operation 

Early  action  keeps 
^  plant  in  a  safe  state 

Accident  Progression 

Fig.  1.  Early  intervention  can  prevent  catastrophic  losses. 

Importance  of  proactivity,  and 
decreasing  effectiveness  as  problem 
intervention  is  delayed  (Burns,  2006) 
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Stage  3:  Defined  information 

exchanges 


•  For  subset  of  detection  tasks,  defined  information  inputs  and  outputs  for 
future  problem/anomaly  detection  automation 

•  Reviewed  and  refined  with  8  SMEs 

•  Systematic  process  for  SMEs  to  indicate  information  availability  and 
information  detail  needed  to  effectively  supervise  automation 

-  ex:  immediate  access  to  general  categories  of  problem  types  and  severity 

-  ex:  on-demand  access  to  precise  values  for  ongoing  and  expected  problem 
duration 

•  HMI  design  concepts  in  forthcoming  conference  paper 

-  Smallman,  H.S.,  &  Cook,  M.B.  (2013).  Proactive  supervisory  decision  support  from 
trend-based  monitoring  of  autonomous  and  automated  systems:  a  tale  of  two 
domains.  HCI International  (HCII)  2013  Invited  Paper,  Las  Vegas,  NV,  21-26  July 
2013. 

-  Novel  trend-based  display  metaphors  for  command  and  control  of  autonomous 
systems 
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Lessons  learned  across  domains 


Smallman,  H.S.,  &  Cook,  M.B.  (2013).  Proactive  supervisory  decision  support  from  trend- 
based  monitoring  of  autonomous  and  automated  systems:  a  tale  of  two  domains.  HCI 
International  (HCII)  2013  Invited  Paper,  Las  Vegas,  NV,  21-26  July  2013. 


Industrial  process  control 


Unmanned  systems 
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Next  steps 


Apply  cognitive  science  to  support  user  abilities 


Cognitive  Human- 

Cognitive  task  automation 

challenges  analyses  allocation 


"Monitoring" 
work  domains 


Cognitive 

science 


Performance 

tradeoffs 


- N 

r  \ 

Allocate 

Define 

tasks 

K 

tasks. 

> 

across 

roles 

V 

users. 

V 

system 

_ J 

l _ ) 

A 


Specify 

info 

exchanges, 

workflow 


Design  & 
prototype 
advanced 
display 
concepts 


> 


Solicit 

user 

feedback 


> 


Conduct 
empirical 
studies  to 
quantify 


inform  design 


Operational  Task,  Automation 

docs  domain  allocation 

feedback  feedback 


Info 

exchanges 


User  task  &  Feedback  on 

display  constraints  concepts,  usage 


Apply  domain,  expertise  to  support  future  task,  needs ■ 


27  military  and  industry  unmanned  systems  subject  matter  experts  (SMEs) 
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Summary  and  application 


•  Abstracted  and  defined  future  autonomous  system 
supervision  tasks 

•  Descriptive  and  prescriptive  allocation  of  tasks  to  humans 
and  automation 

-  Novel,  systematic  approach  for  involving  SMEs  in  allocation  decisions 

•  Developed  organizing  task-centered  framework  for  future 
decision  support 

-  Design 

-  Assessment 

•  Stimulates  design  of  new  C2  metaphors 

-  Novel  trend-based  display  metaphors  for  command  and  control  of 

autonomous  systems  (Smallman  &  Cook,  2013) 

-  Starting  point  and  guidance  for  research  and  design  community 
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